summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaLookup.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Switch the remaining code completions over to LookupVisibleDecls,Douglas Gregor2010-01-141-23/+30
| | | | | | | | after adding the ability to determine whether our lookup is a base-class lookup. Eliminate CollectMemberLookupResults, since it is no longer used (yay). llvm-svn: 93428
* Move code completion for qualified name lookup (foo::) toDouglas Gregor2010-01-141-0/+6
| | | | | | LookupVisibleDecls. Also, a function does not hide another function. llvm-svn: 93421
* Look through using declarations when determining whether one decl hides anotherDouglas Gregor2010-01-141-0/+3
| | | | llvm-svn: 93378
* Name lookup should know better than to look into a class before it's definedDouglas Gregor2010-01-121-1/+3
| | | | llvm-svn: 93217
* When performing name lookup into a scope, check that its entity isDouglas Gregor2010-01-111-1/+1
| | | | | | non-NULL before looking at the entity itself. llvm-svn: 93199
* Implement name lookup for conversion function template specializationsDouglas Gregor2010-01-111-3/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | (C++ [temp.mem]p5-6), which involves template argument deduction based on the type named, e.g., given struct X { template<typename T> operator T*(); } x; when we call x.operator int*(); we perform template argument deduction to determine that T=int. This template argument deduction is needed for template specialization and explicit instantiation, e.g., template<> X::operator float*() { /* ... */ } and when calling or otherwise naming a conversion function (as in the first example). This fixes PR5742 and PR5762, although there's some remaining ugliness that's causing out-of-line definitions of conversion function templates to fail. I'll look into that separately. llvm-svn: 93162
* Fix the search for visible declarations within a Scope to ensure thatDouglas Gregor2010-01-071-13/+15
| | | | | | | | we look into a Scope that corresponds to a compound statement whose scope was combined with the scope of the function that owns it. This improves typo correction in many common cases. llvm-svn: 92879
* Per offline discussion with Doug, don't perform typo correction when we have ↵Ted Kremenek2010-01-061-0/+4
| | | | | | encountered a fatal error. On some files that are woefully wrong (missing headers) this can cause a 3x slowdown in some cases when parsing the file. It makes sense not to perform typo correction in this case because after a fatal error diagnostics will either be suppressed or not really make any sense. llvm-svn: 92809
* Implement typo correction for a variety of Objective-C-specificDouglas Gregor2010-01-031-6/+89
| | | | | | | | | | | | | | constructs: - Instance variable lookup ("foo->ivar" and, in instance methods, "ivar") - Property name lookup ("foo.prop") - Superclasses - Various places where a class name is required - Protocol names (e.g., id<proto>) This seems to cover many of the common places where typos could occur. llvm-svn: 92449
* Make sure that the search for visible declarations looks into the semantic ↵Douglas Gregor2010-01-011-2/+1
| | | | | | parents of out-of-line function contexts llvm-svn: 92397
* Typo correction for member access into classes/structs/unions, e.g.,Douglas Gregor2009-12-311-3/+12
| | | | | | s.fnd("hello") llvm-svn: 92345
* Implement typo correction for id-expressions, e.g.,Douglas Gregor2009-12-311-3/+12
| | | | | | | | | | | | | typo.cpp:22:10: error: use of undeclared identifier 'radious'; did you mean 'radius'? return radious * pi; ^~~~~~~ radius This was super-easy, since we already had decent recovery by looking for names in dependent base classes. llvm-svn: 92341
* Typo correction for type names when they appear in declarations, e.g., givenDouglas Gregor2009-12-301-0/+489
| | | | | | | | | | | | | | | | | | | | | | | | tring str2; we produce the following diagnostic + fix-it: typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'? tring str2; ^~~~~ string To make this really useful, we'll need to introduce typo correction in many more places (wherever we do name lookup), and implement declaration-vs-expression heuristics that cope with typos better. However, for now this will handle the simple cases where we already get good "unknown type name" diagnostics. The LookupVisibleDecls functions are intended to be used by code completion as well as typo correction; that refactoring will happen later. llvm-svn: 92308
* Handle using declarations in overloaded and template functions during ADL andChandler Carruth2009-12-291-8/+5
| | | | | | | | | | address resolution. This fixes PR5751. Also, while we're here, remove logic from ADL which mistakenly included the definition namespaces of overloaded and/or templated functions whose name or address is used as an argument. llvm-svn: 92245
* Look through using decls when checking whether a name is an acceptableJohn McCall2009-12-181-1/+13
| | | | | | | | | | nested-name specifier name. I accidentally checked in the test case for this in the last commit --- fortunately, that refactor was inspired by having debugged this problem already, so I can fix the bug quick (though probably not fast enough for the buildbots). llvm-svn: 91677
* Pull Sema::isAcceptableLookupResult into SemaLookup. Extract the criteria intoJohn McCall2009-12-181-64/+66
| | | | | | | | | | | | | | | different functions and pick the function at lookup initialization time. In theory we could actually divide the criteria functions into N different functions for the N cases, but it's so not worth it. Among other things, lets us invoke LookupQualifiedName without recomputing IDNS info every time. Do some refactoring in SemaDecl to avoid an awkward special case in LQN that was only necessary for redeclaration testing for anonymous structs/unions --- which could be done more efficiently with a scoped lookup anyway. llvm-svn: 91676
* Un-namespace-qualify llvm_unreachable. It's a macro, so the qualification gaveJeffrey Yasskin2009-12-121-1/+1
| | | | | | no extra safety anyway. llvm-svn: 91207
* Patch to fix a crash trying to access a category name inFariborz Jahanian2009-12-111-15/+0
| | | | | | | objective-c++ mode and also removed dead-code in this area. (fixes radar 7456710). llvm-svn: 91081
* Implement redeclaration checking and hiding semantics for using ↵John McCall2009-12-101-1/+10
| | | | | | | | | | | declarations. There are a couple of O(n^2) operations in this, some analogous to the usual O(n^2) redeclaration problem and some not. In particular, retroactively removing shadow declarations when they're hidden by later decls is pretty unfortunate. I'm not yet convinced it's worse than the alternative, though. llvm-svn: 91045
* When performing unqualified name lookup in C++, don't look directlyDouglas Gregor2009-12-081-1/+6
| | | | | | | into transparent contexts; instead, we'll look into their nearest enclosing non-transparent contexts further up the stack. Fixes PR5479. llvm-svn: 90859
* Stop stripping UnresolvedUsingDecls out of LookupResults that have otherJohn McCall2009-12-031-6/+3
| | | | | | | | | results in them (which we were doing intentionally as a stopgap). Fix an DeclContext lookup-table ordering problem which was causing UsingDecls to show up incorrectly when looking for ordinary results. And oh hey Clang-Code-Syntax passes now. llvm-svn: 90367
* Rip out the last remaining implicit use of OverloadedFunctionDecl in Sema:John McCall2009-12-021-39/+1
| | | | | | | LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to return null on overloaded results. llvm-svn: 90309
* Rip out TemplateIdRefExpr and make UnresolvedLookupExpr and John McCall2009-11-241-5/+1
| | | | | | | | | | | | DependentScopeDeclRefExpr support storing templateids. Unite the common code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr. This gets us to a point where we don't need to store function templates in the AST using TemplateNames, which is critical to ripping out OverloadedFunction. Also resolves a few FIXMEs. llvm-svn: 89785
* Consider a FunctionTemplate to be an overload all on its lonesome. TrackJohn McCall2009-11-221-4/+12
| | | | | | this information through lookup rather than rederiving it. llvm-svn: 89570
* "Incremental" progress on using expressions, by which I mean totally rippingJohn McCall2009-11-211-23/+19
| | | | | | | | | | | | | | | | | | | | | | into pretty much everything about overload resolution in order to wean BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the idea of a non-member lookup that we haven't totally resolved yet, whether by overloading, argument-dependent lookup, or (eventually) the presence of a function template in the lookup results. Incidentally fixes a problem with argument-dependent lookup where we were still performing ADL even when the lookup results contained something from a block scope. Incidentally improves a diagnostic when using an ObjC ivar from a class method. This just fell out from rewriting BuildDeclarationNameExpr's interaction with lookup, and I'm too apathetic to break it out. The only remaining uses of OverloadedFunctionDecl that I know of are in TemplateName and MemberExpr. llvm-svn: 89544
* Overhaul previous-declaration and overload checking to work on lookup resultsJohn McCall2009-11-181-1/+5
| | | | | | | rather than NamedDecl*. This is a major step towards eliminating OverloadedFunctionDecl. llvm-svn: 89263
* Split LookupResult into its own header.John McCall2009-11-181-13/+21
| | | | llvm-svn: 89199
* Incremental progress on using declarations. Split UnresolvedUsingDecl intoJohn McCall2009-11-181-5/+17
| | | | | | | | | | two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
* Temporarily unbreak the clang-on-llvm tests. :) Not going to fix unresolvedJohn McCall2009-11-171-9/+1
| | | | | | lookup all in a night. llvm-svn: 89089
* Store "sugared" decls in LookupResults (i.e. decl aliases like using ↵John McCall2009-11-171-9/+14
| | | | | | | | | | | | declarations); strip the sugar off in getFoundDecl() and getAsSingleDecl(), but leave it on for clients like overload resolution who want to use the iterators. Refactor a few pieces of overload resolution to strip off using declarations in a single place. Don't do anything useful with the extra context knowledge yet. llvm-svn: 89061
* Instead of hanging a using declaration's target decls directly off the using John McCall2009-11-171-1/+1
| | | | | | | decl, create shadow declarations and put them in scope like normal. Work in progress. llvm-svn: 89048
* Carry lookup configuration throughout lookup on the LookupResult. GiveJohn McCall2009-11-171-54/+54
| | | | | | | | | | | | | LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics (e.g. access control and deprecation) will be moved to automatically trigger during lookup as part of this same mechanism. This abstraction makes it much easier to encapsulate aliasing declarations (e.g. using declarations) inside the lookup system: eventually, lookup will just produce the aliases in the LookupResult, and the standard access methods will naturally strip the aliases off. llvm-svn: 89027
* First part of changes to eliminate problems with cv-qualifiers andDouglas Gregor2009-11-161-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sugared types. The basic problem is that our qualifier accessors (getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at the current QualType and not at any qualifiers that come from sugared types, meaning that we won't see these qualifiers through, e.g., typedefs: typedef const int CInt; typedef CInt Self; Self.isConstQualified() currently returns false! Various bugs (e.g., PR5383) have cropped up all over the front end due to such problems. I'm addressing this problem by splitting each qualifier accessor into two versions: - the "local" version only returns qualifiers on this particular QualType instance - the "normal" version that will eventually combine qualifiers from this QualType instance with the qualifiers on the canonical type to produce the full set of qualifiers. This commit adds the local versions and switches a few callers from the "normal" version (e.g., isConstQualified) over to the "local" version (e.g., isLocalConstQualified) when that is the right thing to do, e.g., because we're printing or serializing the qualifiers. Also, switch a bunch of Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType() expressions over to Context.hasSameUnqualifiedType(T1, T2) llvm-svn: 88969
* Introduce a new representation for template templateDouglas Gregor2009-11-111-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
* Create a new Scope when parsing a declaration with a C++ scope specifier.John McCall2009-11-111-3/+0
| | | | llvm-svn: 86764
* Fix a similar problem with qualified lookup through using directives,John McCall2009-11-101-1/+1
| | | | | | | although in this case we probably just run a risk of duplicating work; I can't think of how this could cause a bug. llvm-svn: 86680
* Make a somewhat more convincing test case for unqualified lookup throughJohn McCall2009-11-101-1/+2
| | | | | | | | | using directives, and fix a bug thereby exposed: since we're playing tricks with pointers, we need to make certain we're always using the same pointers for things. Also tweak an existing error message. llvm-svn: 86679
* Fix unqualified lookup through using directives.John McCall2009-11-101-83/+168
| | | | | | This is a pretty minimal test case; I'll make a better one later. llvm-svn: 86669
* Ignore dependent bases in ADL. Fixes PR5271.Sebastian Redl2009-10-251-0/+8
| | | | llvm-svn: 85054
* Apply the special enum restrictions from [over.match.oper]p3b2 in ↵Sebastian Redl2009-10-231-2/+12
| | | | | | argument-dependent lookup too. This fixes PR5244. llvm-svn: 84963
* Qualified lookup through using declarations. Diagnose a new type of ambiguity.John McCall2009-10-101-33/+194
| | | | | | | Split the various ambiguous result enumerators into their own enum. Tests for most of C++ [namespace.qual]. llvm-svn: 83700
* Dead Code EliminationDouglas Gregor2009-10-091-20/+0
| | | | llvm-svn: 83686
* Refactor the LookupResult API to simplify most common operations. Require ↵John McCall2009-10-091-545/+226
| | | | | | | | | users to pass a LookupResult reference to lookup routines. Call out uses which assume a single result. llvm-svn: 83674
* Dead code elimination.John McCall2009-10-071-20/+1
| | | | llvm-svn: 83492
* Refactor the code that walks a C++ inheritance hierarchy, searchingDouglas Gregor2009-10-061-14/+39
| | | | | | | | | for bases, members, overridden virtual methods, etc. The operations isDerivedFrom and lookupInBases are now provided by CXXRecordDecl, rather than by Sema, so that CodeGen and other clients can use them directly. llvm-svn: 83396
* Change all the Type::getAsFoo() methods to specializations of Type::getAs().John McCall2009-09-211-6/+6
| | | | | | | | | | | Several of the existing methods were identical to their respective specializations, and so have been removed entirely. Several more 'leaf' optimizations were introduced. The getAsFoo() methods which imposed extra conditions, like getAsObjCInterfacePointerType(), have been left in place. llvm-svn: 82501
* When performing name lookup within a class template or class templateDouglas Gregor2009-09-111-3/+2
| | | | | | | partial specialization, make sure we look into non-dependent base classes (but not dependent base classes). Fixes PR4951. llvm-svn: 81584
* When performing unqualified name lookup into a DeclContext, also look intoDouglas Gregor2009-09-101-20/+22
| | | | | | | | all of the parent DeclContexts that aren't represented within the Scope chain. This fixes some name-lookup problems in out-of-line definitions of members of nested classes. llvm-svn: 81451
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-128/+128
| | | | llvm-svn: 81346
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-23/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | x->Base::f We no longer try to "enter" the context of the type that "x" points to. Instead, we drag that object type through the parser and pass it into the Sema routines that need to know how to perform lookup within member access expressions. We now implement most of the crazy name lookup rules in C++ [basic.lookup.classref] for non-templated code, including performing lookup both in the context of the type referred to by the member access and in the scope of the member access itself and then detecting ambiguities when the two lookups collide (p1 and p4; p3 and p7 are still TODO). This change also corrects our handling of name lookup within template arguments of template-ids inside the nested-name-specifier (p6; we used to look into the scope of the object expression for them) and fixes PR4703. I have disabled some tests that involve member access expressions where the object expression has dependent type, because we don't yet have the ability to describe dependent nested-name-specifiers starting with an identifier. llvm-svn: 80843
OpenPOWER on IntegriCloud