summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-applies the patch first applied way back in r106099, withChandler Carruth2011-05-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | accompanying fixes to make it work today. The core of this patch is to provide a link from a TemplateTypeParmType back to the TemplateTypeParmDecl node which declared it. This in turn provides much more precise information about the type, where it came from, and how it functions for AST consumers. To make the patch work almost a year after its first attempt, it needed serialization support, and it now retains the old getName() interface. Finally, it requires us to not attempt to instantiate the type in an unsupported friend decl -- specifically those coming from template friend decls but which refer to a specific type through a dependent name. A cleaner representation of the last item would be to build FriendTemplateDecl nodes for these, storing their template parameters etc, and to perform proper instantation of them like any other template declaration. They can still be flagged as unsupported for the purpose of access checking, etc. This passed an asserts-enabled bootstrap for me, and the reduced test case mentioned in the original review thread no longer causes issues, likely fixed at somewhere amidst the 24k revisions that have elapsed. llvm-svn: 130628
* r130381 follow up: accept __uuidof expression for template argument reference.Francois Pichet2011-04-291-2/+6
| | | | llvm-svn: 130491
* Update r130381 to check for UO_AddrOf.Francois Pichet2011-04-281-9/+8
| | | | llvm-svn: 130384
* Support &__uuidof(type) as a non type template argument.Francois Pichet2011-04-281-0/+9
| | | | | | | | | | | | | | | This idiom is used everywhere in MFC/COM code and as such this patch removes hundreds of errors when parsing MFC code with clang. Example: template <class T, const GUID* g = &__uuidof(T)> class ComTemplate { }; typedef ComTemplate<struct_with_uuid, &__uuidof(struct_with_uuid)> COM_TYPE; Of course this is just parsing support. Trying to use this in CodeGen will generate: error: cannot yet mangle expression type CXXUuidofExpr llvm-svn: 130381
* Extend Sema::ClassifyName() to support C++, ironing out a few issuesDouglas Gregor2011-04-271-1/+1
| | | | | | | | | in the classification of template names and using declarations. We now properly typo-correct the leading identifiers in statements to types, templates, values, etc. As an added bonus, this reduces the number of lookups required for disambiguation. llvm-svn: 130288
* fix PR9474, a crash with -fshort-enum and C++ templates: when instantiatingChris Lattner2011-04-251-10/+9
| | | | | | | the enum decl, we need to use an integer type the same size as the enumerator, which may not be the promoted type with packed enums. llvm-svn: 130148
* Implement a new identifier-classification scheme where SemaDouglas Gregor2011-04-241-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | performs name lookup for an identifier and resolves it to a type/expression/template/etc. in the same step. This scheme is intended to improve both performance (by reducing the number of redundant name lookups for a given identifier token) and error recovery (by giving Sema a chance to correct type names before the parser has decided that the identifier isn't a type name). For example, this allows us to properly typo-correct type names at the beginning of a statement: t.c:6:3: error: use of undeclared identifier 'integer'; did you mean 'Integer'? integer *i = 0; ^~~~~~~ Integer t.c:1:13: note: 'Integer' declared here typedef int Integer; ^ Previously, we wouldn't give a Fix-It because the typo correction occurred after the parser had checked whether "integer" was a type name (via Sema::getTypeName(), which isn't allowed to typo-correct) and therefore decided to parse "integer * i = 0" as an expression. By typo-correcting earlier, we typo-correct to the type name Integer and parse this as a declaration. Moreover, in this context, we can also typo-correct identifiers to keywords, e.g., t.c:7:3: error: use of undeclared identifier 'vid'; did you mean 'void'? vid *p = i; ^~~ void and recover appropriately. Note that this is very much a work-in-progress. The new Sema::ClassifyName is only used for expression-or-declaration disambiguation in C at the statement level. The next steps will be to make this work for the same disambiguation in C++ (where functional-style casts make some trouble), then push it further into the parser to eliminate more redundant name lookups. Fixes <rdar://problem/7963833> for C and starts us down the path of <rdar://problem/8172000>. llvm-svn: 130082
* Add -fdelayed-template-parsing option. Using this option all templated ↵Francois Pichet2011-04-221-0/+21
| | | | | | | | | function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
* Support for C++11 (non-template) alias declarations.Richard Smith2011-04-151-2/+2
| | | | llvm-svn: 129567
* Use ExprResult& instead of Expr *& in SemaJohn Wiegley2011-04-081-59/+65
| | | | | | | | | | | | | | | | | | | | | | | | | This patch authored by Eric Niebler. Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr pointers as in/out parameters (Expr *&). This is especially true for the routines that apply implicit conversions to nodes in-place. This design is workable only as long as those conversions cannot fail. If they are allowed to fail, they need a way to report their failures. The typical way of doing this in clang is to use an ExprResult, which has an extra bit to signal a valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema interface. We suggest changing the Expr *& parameters in the Sema interface to ExprResult &. This increases interface consistency and maintainability. This interface change is important for work supporting MS-style C++ properties. For reasons explained here <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>, seemingly trivial operations like rvalue/lvalue conversions that formerly could not fail now can. (The reason is that given the semantics of the feature, getter/setter method lookup cannot happen until the point of use, at which point it may be found that the method does not exist, or it may have the wrong type, or overload resolution may fail, or it may be inaccessible.) llvm-svn: 129143
* Make helpers static.Benjamin Kramer2011-03-261-1/+2
| | | | llvm-svn: 128339
* Fixed inconsistency when adding TemplateParameterListsInfo.Abramo Bagnara2011-03-181-15/+20
| | | | llvm-svn: 127876
* Don't ask if a depenendent CXXRecordDecl has any dependent basesDouglas Gregor2011-03-111-1/+2
| | | | | | | unless we already know that it has a definition. Fixes PR9449/<rdar://problem/9115785>. llvm-svn: 127512
* Avoid do drop outer template parameter lists on the floor.Abramo Bagnara2011-03-101-2/+10
| | | | llvm-svn: 127404
* Fixed InnerLocStart.Abramo Bagnara2011-03-091-4/+5
| | | | llvm-svn: 127330
* Fixed source range for all DeclaratorDecl's.Abramo Bagnara2011-03-081-0/+1
| | | | llvm-svn: 127225
* Fixed TypedefDecl and TemplateTypeParameter source range.Abramo Bagnara2011-03-061-2/+2
| | | | llvm-svn: 127119
* Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdTypeDouglas Gregor2011-03-041-4/+32
| | | | | | | | to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
* Make sure to put template parameters into their owning template'sDouglas Gregor2011-03-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext once we've created it. This mirrors what we do for function parameters, where the parameters start out with translation-unit context and then are adopted by the appropriate DeclContext when it is created. Also give template parameters public access and make sure that they don't show up for the purposes of name lookup. Fixes PR9400, a regression introduced by r126920, which implemented substitution of default template arguments provided in template template parameters (C++ core issue 150). How on earth could the DeclContext of a template parameter affect the handling of default template arguments? I'm so glad you asked! The link is Sema::getTemplateInstantiationArgs(), which determines the outer template argument lists that correspond to a given declaration. When we're instantiating a default template argument for a template template parameter within the body of a template definition (not it's instantiation, per core issue 150), we weren't getting any outer template arguments because the context of the template template parameter was the translation unit. Now that the context of the template template parameter is its owning template, we get the template arguments from the injected-class-name of the owning template, so substitution works as it should. llvm-svn: 127004
* Fixed source range for function template specializations.Abramo Bagnara2011-03-041-5/+11
| | | | | | | | | | | template <class T> void foo(); template <> void foo<int>(); /* Spec 1 */ template <> void foo<int>(); /* Spec 2 */ If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1. Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location). llvm-svn: 127002
* When we use the default template arguments of a template templateDouglas Gregor2011-03-031-3/+10
| | | | | | | | | | | | | parameter, save the instantiated default template arguments along with the explicitly-specified template argument list. That way, we prefer the default template template arguments corresponding to the template template parameter rather than those of its template template argument. This addresses the likely direction of C++ core issue 150, and fixes PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of EDG and GCC. llvm-svn: 126920
* Kill off the TreeTransform::TransformTemplateName overload that hasDouglas Gregor2011-03-021-8/+6
| | | | | | poor source-location information. llvm-svn: 126852
* Push nested-name-specifier source location information into templateDouglas Gregor2011-03-021-16/+32
| | | | | | | | | | | | template arguments. I believe that this is the last place in the AST where we were storing a source range for a nested-name-specifier rather than a proper nested-name-specifier location structure. (Yay!) There is still a lot of cleanup to do in the TreeTransform, which doesn't take advantage of nested-name-specifiers with source-location information everywhere it could. llvm-svn: 126844
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-021-42/+98
| | | | | | | | | | | | | | | | | | | | | | | | template specialization types. This also required some parser tweaks, since we were losing track of the nested-name-specifier's source location information in several places in the parser. Other notable changes this required: - Sema::ActOnTagTemplateIdType now type-checks and forms the appropriate type nodes (+ source-location information) for an elaborated-type-specifier ending in a template-id. Previously, we used a combination of ActOnTemplateIdType and ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped around a DependentTemplateSpecializationType, which duplicated the keyword ("class", "struct", etc.) and nested-name-specifier storage. - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which it places into the returned type-source location information. - Sema::ActOnDependentTag now creates types with source-location information. llvm-svn: 126808
* Push nested-name-specifier source-location information into dependentDouglas Gregor2011-03-011-4/+6
| | | | | | | | template specialization types. There are still a few rough edges to clean up with some of the parser actions dropping nested-name-specifiers too early. llvm-svn: 126776
* Reinstate the introduction of source-location information forDouglas Gregor2011-03-011-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | nested-name-speciciers within elaborated type names, e.g., enum clang::NestedNameSpecifier::SpecifierKind Fixes in this iteration include: (1) Compute the type-source range properly for a dependent template specialization type that starts with "template template-id ::", as in a member access expression dep->template f<T>::f() This is a latent bug I triggered with this change (because now we're checking the computed source ranges for dependent template specialization types). But the real problem was... (2) Make sure to set the qualifier range on a dependent template specialization type appropriately. This will go away once we push nested-name-specifier locations into dependent template specialization types, but it was the source of the valgrind errors on the buildbots. llvm-svn: 126765
* Revert r126748, my second attempt at nested-name-specifier sourceDouglas Gregor2011-03-011-7/+6
| | | | | | location information for elaborated types. *sigh* llvm-svn: 126753
* When building a type for a typename specifier, check specifically forDouglas Gregor2011-03-011-40/+34
| | | | | | | | | a dependent template name rather than (indirectly and incorrectly) trying to determine whether we can compute a context for the nested-name-specifier. Fixes a GCC testsuite regression, <rdar://problem/9068589>. llvm-svn: 126749
* Reinstate r126737, extending the generation of type-source locationDouglas Gregor2011-03-011-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | information for qualifier type names throughout the parser to address several problems. The commit message from r126737: Push nested-name-specifier source location information into elaborated name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. llvm-svn: 126748
* Revert r126737, the most recent nested-name-specifier location change, for ↵Douglas Gregor2011-03-011-8/+12
| | | | | | buildbot breakage. llvm-svn: 126746
* Push nested-name-specifier source location information into elaboratedDouglas Gregor2011-03-011-12/+8
| | | | | | | | | | | | | | | | | | | name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind". Aside from the normal changes, this also required some tweaks to the parser. Essentially, when we're looking at a type name (via getTypeName()) specifically for the purpose of creating an annotation token, we pass down the flag that asks for full type-source location information to be stored within the returned type. That way, we retain source-location information involving nested-name-specifiers rather than trying to reconstruct that information later, long after it's been lost in the parser. With this change, test/Index/recursive-cxx-member-calls.cpp is showing much improved results again, since that code has lots of nested-name-specifiers. llvm-svn: 126737
* Push nested-name-specifier source location information intoDouglas Gregor2011-03-011-3/+3
| | | | | | | | | | | | DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to walk DependentNameTypeLoc nodes. Also, teach libclang about TypedefDecl source ranges, so that we get those. The massive churn in test/Index/recursive-cxx-member-calls.cpp is a good thing: we're annotating a lot more of this test correctly now. llvm-svn: 126729
* Teach Sema::CheckTypenameType to use nested-name-specifiers withDouglas Gregor2011-02-281-16/+21
| | | | | | | | source-location information. We don't actually preserve this information in any of the resulting TypeLocs (yet), so it doesn't matter. llvm-svn: 126693
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-10/+3
| | | | | | | | | | | | | UnresolvedLookupExpr and UnresolvedMemberExpr. Also, improve the computation that checks whether the base of a member expression (either unresolved or dependent-scoped) is implicit. The previous check didn't cover all of the cases we use in our representation, which threw off source-location information for these expressions (which, in turn, caused some breakage in libclang's token annotation). llvm-svn: 126681
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-4/+1
| | | | | | | | CXXDependentScopeMemberExpr, and clean up instantiation of nested-name-specifiers with dependent template specialization types in the process. llvm-svn: 126663
* Eliminate the last remains of TemplateSpecializationTypes withDouglas Gregor2011-02-281-0/+20
| | | | | | | | dependent template names. There is still a lot of redundant code in TreeTransform to cope with TemplateSpecializationTypes, which I'll remove in stages. llvm-svn: 126656
* Eliminate a silly little Parse/Sema dance when parsing typenameDouglas Gregor2011-02-271-48/+60
| | | | | | | | | | | | | | | | | | | specifiers such as typename T::template apply<U> Previously, we would turn T::template apply<U> into a TemplateSpecializationType. Then, we'd reprocess that TemplateSpecializationType and turn it into either a TemplateSpecializationType wrapped in an ElaboratedType (when we could resolve "apply" to a template declaration) or a DependentTemplateSpecializationType. We now produce the same ASTs but without generating the intermediate TemplateSpecializationType. The end goal here is to avoid generating TemplateSpecializationTypes with dependent template-names, ever. We're not there yet. llvm-svn: 126589
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-251-4/+7
| | | | | | | DependentScopeDeclRefExpr. Plus, give NestedNameSpecifierLoc == and != operators, since we're going to need 'em elsewhere. llvm-svn: 126508
* Switch a few CXXScopeSpec::MakeTrivial() calls over to appropriateDouglas Gregor2011-02-251-6/+8
| | | | | | NestedNameSpecifierLoc handling. llvm-svn: 126486
* Use NestedNameSpecifierLoc within out-of-line variables, function, andDouglas Gregor2011-02-251-2/+1
| | | | | | | tag definitions. Also, add support for template instantiation of NestedNameSpecifierLocs. llvm-svn: 126470
* Update UsingDecl, UnresolvedUsingTypenameDecl, andDouglas Gregor2011-02-251-1/+1
| | | | | | | | | | | | | | UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the extremely-lossy NestedNameSpecifier/SourceRange pair it used to use, improving source-location information. Various infrastructure updates to support NestedNameSpecifierLoc: - AST/PCH (de-)serialization - Recursive AST visitor - libclang traversal (including the first tests of this functionality) llvm-svn: 126459
* Retain complete source-location information for C++Douglas Gregor2011-02-241-3/+3
| | | | | | | | | | | | nested-name-specifiers throughout the parser, and provide a new class (NestedNameSpecifierLoc) that contains a nested-name-specifier along with its type-source information. Right now, this information is completely useless, because we don't actually store the source-location information anywhere in the AST. Call this Step 1/N. llvm-svn: 126391
* Teach NestedNameSpecifier to keep track of namespace aliases the sameDouglas Gregor2011-02-241-0/+1
| | | | | | | | way it keeps track of namespaces. Previously, we would map from the namespace alias to its underlying namespace when building a nested-name-specifier, losing source information in the process. llvm-svn: 126358
* Tweak the CXXScopeSpec API a bit, so that we require theDouglas Gregor2011-02-241-4/+3
| | | | | | nested-name-specifier and source range to be set at the same time. llvm-svn: 126347
* Implement the C++0x deduced 'auto' feature.Richard Smith2011-02-201-0/+4
| | | | | | This fixes PR 8738, 9060 and 9132. llvm-svn: 126069
* Handle the resolution of a reference to a function template (whichDouglas Gregor2011-02-191-0/+5
| | | | | | | | includes explicitly-specified template arguments) to a function template specialization in cases where no deduction is performed or deduction fails. Patch by Faisal Vali, fixes PR7505! llvm-svn: 126048
* When we're creating an expression for an integral template argument ofDouglas Gregor2011-02-181-2/+9
| | | | | | | | | | | | | enumeration type, we were generating an integer literal implicitly casted to the appropriate enumeration type. However, later checks on that expression would strip the implicit cast. This commit tweaks the lame hack, by creating an explicit cast instead of an implicit cast. The right answer is to introduce a SubstNonTypeTemplateParmExpr expression that acts like the substituted result. I'll investigate that soon. llvm-svn: 125818
* Tweak my fix for PR8748, and update the incorrect PR number in the test case.Douglas Gregor2011-02-041-1/+2
| | | | llvm-svn: 124863
* Tighten up the semantics of default template arguments, per C++0xDouglas Gregor2011-02-041-2/+9
| | | | | | [temp.param]p9 and C++ DR226. Fixes PR8747. llvm-svn: 124856
* When a function template's template parameter has a default argument,Douglas Gregor2011-02-041-2/+2
| | | | | | | | | | it's okay for the following template parameters to not have default arguments (since those template parameters can still be deduced). Also, downgrade the error about default template arguments in function templates to an extension warning, since this is a harmless C++0x extension. llvm-svn: 124855
OpenPOWER on IntegriCloud