That's what I get for hurredly splitting the small change out of a much
bigger change that had moved where checkCorrectionVisibility was being
called.
llvm-svn: 211134
Also move the constructor for NamespaceSpecifierSet out of line to
improve the class' readability. I meant to do these two things while
cleaning up the previous TypoCorrectionConsumer changes and have them
folded into those changes.
No functionality changed.
llvm-svn: 210686
SpecifierInfo is not used outside of NamespaceSpecifierSet except
indirectly through NamespaceSpecifierSet's iterator, so clean up the
code a bit by moving SpecifierInfo into NamespaceSpecifierSet. Also drop
SpecifierInfo's trivial yet verbose constructor since brace
initiialization is sufficient in the only two places the constructor was
being explicitly called.
No functionality changed.
llvm-svn: 210672
The SpecifierInfo and NamespaceSpecifierSet are now only used by
TypoCorrectionConsumer, so treat them as the implementation details of
TypoCorrectionConsumer that they are. Also make NamespaceSpecifierSet's
method names more style guide compliant.
No functionality changed.
llvm-svn: 210671
The only external/visible functional change that fell out of this
refactoring is that there was one less case where the typo caching
and/or counting didn't work properly. The result is that a test case
had to be moved from typo-correction.cpp to typo-correction-pt2.cpp
to avoid the hard-coded limit on per file/TU typo correction attempts.
llvm-svn: 210669
This is in preparation for moving TypoCorrection filtering
into the TypoCorrectionConsumer, to separate out some of the purely
mechanical churn. It also makes some of the method names in
NamespaceSpecifierSet be more style guide compliant.
No functionality changed.
llvm-svn: 210668
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
llvm-svn: 208150
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
llvm-svn: 205653
complete. We hook into this check from a couple of other places (modules,
debug info) so it's not OK to elide the check if the type was already
complete.
llvm-svn: 203978
Because in C++, "anonymous" doesn't mean "nameless" for records. In
other words, RecordDecl::isAnonymousStructOrUnion only returns true if
the record lacks a name *and* is not used as the type in an object's
declaration.
llvm-svn: 200868
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
