summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaCXXScopeSpec.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Restore the invariant that a nested-name-specifier can only containDouglas Gregor2010-02-251-28/+14
| | | | | | | | | class types, dependent types, and namespaces. I had previously weakened this invariant while working on parsing pseudo-destructor expressions, but recent work in that area has made these changes unnecessary. llvm-svn: 97112
* ActOnPseudoDestructorExpr now performs all semantic analysis forDouglas Gregor2010-02-241-0/+48
| | | | | | | | | | | | | | | | pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr node directly. Currently, this only affects pseudo-destructor expressions when they are parsed, but not after template instantiation. That's coming next... Improve parsing of pseudo-destructor-names. When parsing the nested-name-specifier and we hit the sequence of tokens X :: ~, query the actual module to determine whether X is a type-name (in which case the X :: is part of the pseudo-destructor-name but not the nested-name-specifier) or not (in which case the X :: is part of the nested-name-specifier). llvm-svn: 97058
* Implement support for parsing pseudo-destructor expression with a ↵Douglas Gregor2010-02-211-14/+28
| | | | | | | | | | | | nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
* When determining whether a scope specifier is complete, consider aDouglas Gregor2010-02-051-0/+4
| | | | | | dependent DeclContext to be "complete". Fixes PR6236. llvm-svn: 95359
* Teach Sema::ActOnDependentTemplateName that a dependent template nameDouglas Gregor2010-01-191-22/+0
| | | | | | | | in a member access expression referring into the current instantiation need not be resolved at template definition *if* the current instantiation has any dependent base classes. Fixes PR6081. llvm-svn: 93877
* When determining whether the type is the current instantiation, stripDouglas Gregor2010-01-151-2/+2
| | | | | | qualifiers. Fixes PR6021. llvm-svn: 93513
* When qualified lookup into the current instantiation fails (because itDouglas Gregor2010-01-141-0/+22
| | | | | | | | finds nothing), and the current instantiation has dependent base classes, treat the qualified lookup as if it referred to an unknown specialization. Fixes PR6031. llvm-svn: 93433
* Whenever we emit a typo-correction diagnostic, also emit a noteDouglas Gregor2010-01-071-0/+4
| | | | | | | pointing to the declaration that we found that has that name (if it is unique). llvm-svn: 92877
* Typo correction for identifiers within nested name specifiers, e.g.,Douglas Gregor2009-12-311-0/+22
| | | | | | | | | | typo.cpp:18:1: error: use of undeclared identifier 'other_std'; did you mean 'otherstd'? other_std::strng str1; ^~~~~~~~~ otherstd llvm-svn: 92350
* Fix typo in commentDouglas Gregor2009-12-301-1/+1
| | | | llvm-svn: 92307
* Refactor to remove more dependencies on PreDeclaratorDC. I seem to have madeJohn McCall2009-12-191-11/+15
| | | | | | | the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can live with that; they'll need to be fixed more holistically anyhow. llvm-svn: 91771
* Don't enter a new scope for a namespace-qualified declarator unless we'reJohn McCall2009-12-111-0/+38
| | | | | | | in a file context. In well-formed code, only happens with friend functions. Fixes PR 5760. llvm-svn: 91146
* reapply my patch for PR4451, which improves diagnostics for :: vs : confusion.Chris Lattner2009-12-071-4/+39
| | | | | | This time with a fix to bail out when in a dependent context. llvm-svn: 90730
* revert my previous patch, it is breaking something and I don't have timeChris Lattner2009-12-061-32/+4
| | | | | | to fix it ATM. llvm-svn: 90717
* implement PR4451, improving error recovery for a mistaken : where a :: wasChris Lattner2009-12-061-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | intended. On the first testcase in the bug, we now produce: cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier y:a a2; ^ :: instead of: t.cc:8:1: error: C++ requires a type specifier for all declarations x:a a2; ^ t.cc:8:2: error: invalid token after top level declarator x:a a2; ^ ; t.cc:9:11: error: use of undeclared identifier 'a2' x::a a3 = a2; ^ llvm-svn: 90713
* Rip out the last remaining implicit use of OverloadedFunctionDecl in Sema:John McCall2009-12-021-6/+8
| | | | | | | LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to return null on overloaded results. llvm-svn: 90309
* Split LookupResult into its own header.John McCall2009-11-181-0/+1
| | | | llvm-svn: 89199
* Carry lookup configuration throughout lookup on the LookupResult. GiveJohn McCall2009-11-171-13/+15
| | | | | | | | | | | | | 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
* When starting a C++ member access expression, make sure to compute theDouglas Gregor2009-11-041-63/+68
| | | | | | | | | type of the object even when it is dependent. Specifically, this makes sure that we get the right type for "this->", which is important when performing name lookup into this scope to determine whether an identifier or operator-function-id is a template name. llvm-svn: 86060
* Unify our diagnostic printing for errors of the form, "we didn't likeDouglas Gregor2009-10-131-3/+1
| | | | | | | | | | what we found when we looked into <blah>", where <blah> is a DeclContext*. We can now format DeclContext*'s in nice ways, e.g., "namespace N", "the global namespace", "'class Foo'". This is part of PR3990, but we're not quite there yet. llvm-svn: 84028
* Refactor the LookupResult API to simplify most common operations. Require ↵John McCall2009-10-091-20/+23
| | | | | | | | | users to pass a LookupResult reference to lookup routines. Call out uses which assume a single result. llvm-svn: 83674
* When entering the scope of a declarator, make sure that the scope isDouglas Gregor2009-09-241-2/+10
| | | | | | | | complete (or, possibly causing template instantiation). Test this via some explicit specializations of member functions. llvm-svn: 82732
* Implement code completion for tags, e.g., code completion after "enum"Douglas Gregor2009-09-181-4/+4
| | | | | | | | | | | | | will provide the names of various enumerations currently visible. Introduced filtering of code-completion results when we build the result set, so that we can identify just the kinds of declarations we want. This implementation is incomplete for C++, since we don't consider that the token after the tag keyword could start a nested-name-specifier. llvm-svn: 82222
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-63/+63
| | | | llvm-svn: 81346
* Improve template instantiation for member access expressions thatDouglas Gregor2009-09-031-37/+88
| | | | | | | | | involve qualified names, e.g., x->Base::f. We now maintain enough information in the AST to compare the results of the name lookup of "Base" in the scope of the postfix-expression (determined at template definition time) and in the type of the object expression. llvm-svn: 80953
* Add a wicked little test-case that illustrates what we have to dealDouglas Gregor2009-09-021-1/+5
| | | | | | | | with to properly support member access expressions in templates. This test is XFAIL'd, because we get it completely wrong, but I've made the minimal changes to the representation to at least avoid a crash. llvm-svn: 80856
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-85/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* More missing member goodness.Anders Carlsson2009-08-301-3/+6
| | | | llvm-svn: 80491
* Improve diagnostics for missing members. This renames the ↵Anders Carlsson2009-08-301-1/+1
| | | | | | err_typecheck_no_member to err_typecheck_no_member_deprecated. The idea is that err_typecheck_no_member_deprecated should be phased out and any call sites that reference it should call DiagnoseMissingMember instead. llvm-svn: 80469
* Bye-bye old RequireCompleteType.Anders Carlsson2009-08-261-2/+3
| | | | llvm-svn: 80182
* Improve diagnostics and recovery when the nested-name-specifier of aDouglas Gregor2009-08-261-16/+6
| | | | | | | | | | | | qualified name does not actually refer into a class/class template/class template partial specialization. Improve printing of nested-name-specifiers to eliminate redudant qualifiers. Also, make it possible to output a nested-name-specifier through a DiagnosticBuilder, although there are relatively few places that will use this leeway. llvm-svn: 80056
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | their members, including member class template, member function templates, and member classes and functions of member templates. To actually parse the nested-name-specifiers that qualify the name of an out-of-line definition of a member template, e.g., template<typename X> template<typename Y> X Outer<X>::Inner1<Y>::foo(Y) { return X(); } we need to look for the template names (e.g., "Inner1") as a member of the current instantiation (Outer<X>), even before we have entered the scope of the current instantiation. Since we can't do this in general (i.e., we should not be looking into all dependent nested-name-specifiers as if they were the current instantiation), we rely on the parser to tell us when it is parsing a declaration specifier sequence, and, therefore, when we should consider the current scope specifier to be a current instantiation. Printing of complicated, dependent nested-name-specifiers may be somewhat broken by this commit; I'll add tests for this issue and fix the problem (if it still exists) in a subsequent commit. llvm-svn: 80044
* Use Sema's LocInfoType to pass and preserve type source info through the Parser.Argyrios Kyrtzidis2009-08-191-1/+1
| | | | llvm-svn: 79395
* Take 2 on AltiVec-style vector initializers. Nate Begeman2009-08-101-0/+3
| | | | | | | | | | | | Fixes PR4704 problems Addresses Eli's patch feedback re: ugly cast code Updates all postfix operators to remove ParenListExprs. While this is awful, no better solution (say, in the parser) is obvious to me. Better solutions welcome. llvm-svn: 78621
* Support nested-name-specifiers for C++ member access expressions, e.g.,Douglas Gregor2009-08-061-0/+50
| | | | | | | | this->Base::foo from James Porter! llvm-svn: 78278
* Remove a redundant getCanonicalType callDouglas Gregor2009-07-311-1/+1
| | | | llvm-svn: 77702
* What luck! Clang obtains support for refering to members of theDouglas Gregor2009-07-301-1/+2
| | | | | | | current instantiation when that current instantiation is a class template partial specialization. llvm-svn: 77609
* Support out-of-line definitions of the members of class templateDouglas Gregor2009-07-301-2/+12
| | | | | | partial specializations. llvm-svn: 77606
* Change uses of:Ted Kremenek2009-07-291-2/+2
| | | | | | | | | | | | | | | | | | | | Type::getAsReferenceType() -> Type::getAs<ReferenceType>() Type::getAsRecordType() -> Type::getAs<RecordType>() Type::getAsPointerType() -> Type::getAs<PointerType>() Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>() Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>() Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>() Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>() Type::getAsReferenceType() -> Type::getAs<ReferenceType>() Type::getAsTagType() -> Type::getAs<TagType>() And remove Type::getAsReferenceType(), etc. This change is similar to one I made a couple weeks ago, but that was partly reverted pending some additional design discussion. With Doug's pending smart pointer changes for Types, it seemed natural to take this approach. llvm-svn: 77510
* Implement support for out-of-line definitions of the class members of classDouglas Gregor2009-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | templates, e.g., template<typename T> struct Outer { struct Inner; }; template<typename T> struct Outer<T>::Inner { // ... }; Implementing this feature required some extensions to ActOnTag, which now takes a set of template parameter lists, and is the precursor to removing the ActOnClassTemplate function from the parser Action interface. The reason for this approach is simple: the parser cannot tell the difference between a class template definition and the definition of a member of a class template; both have template parameter lists, and semantic analysis determines what that template parameter list means. There is still some cleanup to do with ActOnTag and ActOnClassTemplate. This commit provides the basic functionality we need, however. llvm-svn: 76820
* Complain if we're entering the context of a dependent nested-name-specifier butDouglas Gregor2009-07-221-1/+13
| | | | | | | cannot match that nested-name-specifier to a class template or class template partial specialization. llvm-svn: 76704
* Basic parsing and semantic analysis for out-of-line definitions of theDouglas Gregor2009-07-211-7/+43
| | | | | | | | | | | | | member functions of class templates, e.g., template<typename T> struct X { void f(T); }; template<typename T> X<T>::f(T) { /* ... */ } llvm-svn: 76692
* Make Sema::ActOnCXXEnterDeclaratorScope robust against failures to computeDouglas Gregor2009-07-211-3/+8
| | | | | | | the declaration context, as occurs with out-of-line class template member definitions. llvm-svn: 76622
* Per offline discussion with Steve Naroff, add back Type::getAsXXXType() methodsTed Kremenek2009-07-171-2/+2
| | | | | | | | | until Doug Gregor's Type smart pointer code lands (or more discussion occurs). These methods just call the new Type::getAs<XXX> methods, so we still have reduced implementation redundancy. Having explicit getAsXXXType() methods makes it easier to set breakpoints in the debugger. llvm-svn: 76193
* Replaced Type::getAsLValueReferenceType(), Type::getAsRValueReferenceType(), ↵Ted Kremenek2009-07-171-2/+2
| | | | | | Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents. llvm-svn: 76139
* Factor out some common code into ↵Argyrios Kyrtzidis2009-06-171-13/+2
| | | | | | Sema::EnterDeclaratorContext/ExitDeclaratorContext. llvm-svn: 73655
* Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor2009-05-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | template<typename T> struct X { struct Inner; }; template struct X<int>::Inner; This change is larger than it looks because it also fixes some a problem with nested-name-specifiers and tags. We weren't requiring the DeclContext associated with the scope specifier of a tag to be complete. Therefore, when looking for something like "struct X<int>::Inner", we weren't instantiating X<int>. This, naturally, uncovered a problem with member pointers, where we were requiring the left-hand side of a member pointer access expression (e.g., x->*) to be a complete type. However, this is wrong: the semantics of this expression does not require a complete type (EDG agrees). Stuart vouched for me. Blame him. llvm-svn: 71756
* Implement the notions of the "current instantiation" and "unknownDouglas Gregor2009-05-111-5/+97
| | | | | | | | | | | | | | | | | | specialization" within a C++ template, and permit name lookup into the current instantiation. For example, given: template<typename T, typename U> struct X { typedef T type; X* x1; // current instantiation X<T, U> *x2; // current instantiation X<U, T> *x3; // not current instantiation ::X<type, U> *x4; // current instantiation X<typename X<type, U>::type, U>: *x5; // current instantiation }; llvm-svn: 71471
* More improvements to namespace aliases. We now support everything except ↵Anders Carlsson2009-03-281-0/+4
| | | | | | aliases in using directives. llvm-svn: 67966
* Initial implementation of parsing, semantic analysis, and templateDouglas Gregor2009-03-271-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | instantiation for C++ typename-specifiers such as typename T::type The parsing of typename-specifiers is relatively easy thanks to annotation tokens. When we see the "typename", we parse the typename-specifier and produce a typename annotation token. There are only a few places where we need to handle this. We currently parse the typename-specifier form that terminates in an identifier, but not the simple-template-id form, e.g., typename T::template apply<U, V> Parsing of nested-name-specifiers has a similar problem, since at this point we don't have any representation of a class template specialization whose template-name is unknown. Semantic analysis is only partially complete, with some support for template instantiation that works for simple examples. llvm-svn: 67875
OpenPOWER on IntegriCloud