summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Fix whitespace.NAKAMURA Takumi2011-01-271-485/+485
| | | | llvm-svn: 124364
* 7bit-ize.NAKAMURA Takumi2011-01-271-6/+6
| | | | llvm-svn: 124363
* When we run into a template parameter that should have a defaultDouglas Gregor2011-01-271-1/+19
| | | | | | | | | | argument but doesn't (because previous template parameters had default arguments), clear out all of the default arguments so that we maintain the invariant that a template parameter has a default argument only if subsequence template parameters also have default arguments. Fixes a crash-on-invalid <rdar://problem/8913649>. llvm-svn: 124345
* Fix a horrible bug in our handling of C-style casting, where a C-styleDouglas Gregor2011-01-271-4/+5
| | | | | | | | | | | derived-to-base cast that also casts away constness (one of the cases for static_cast followed by const_cast) would be treated as a bit-cast rather than a derived-to-base class, causing miscompiles and heartburn. Fixes <rdar://problem/8913298>. llvm-svn: 124340
* Teach TemplateSpecializationTypeLoc::initializeArgLocs() to actuallyDouglas Gregor2011-01-251-2/+4
| | | | | | | | | generate meaningful [*] template argument location information. [*] Well, as meaningful as possible, given that this entire code path is a hack for when we've lost type-source information. llvm-svn: 124211
* Re-instate r123977/r123978, my updates of the reference-bindingDouglas Gregor2011-01-241-0/+1
| | | | | | | | | | | | | | | | implementation used by overload resolution to support rvalue references. The original commits caused PR9026 and some hard-to-reproduce self-host breakage. The only (crucial!) difference between this commit and the previous commits is that we now properly check the SuppressUserConversions flag before attempting to perform a second user-defined conversion in reference binding, breaking the infinite recursion chain of user-defined conversions. Rvalue references should be working a bit better now. llvm-svn: 124121
* revert r123977 and r123978 to fix PR9026.Rafael Espindola2011-01-221-1/+0
| | | | llvm-svn: 124033
* Update the reference-binding implementation used for overloadDouglas Gregor2011-01-211-0/+1
| | | | | | | | resolution to match the latest C++0x working paper's semantics. The implementation now matching up with the reference-binding implementation used for initialization. llvm-svn: 123977
* Implement support for non-type template parameter packs whose type isDouglas Gregor2011-01-191-2/+49
| | | | | | | | | | | | | | | | | | | | | a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
* Change QualType::getTypePtr() to return a const pointer, then change aJohn McCall2011-01-191-2/+2
| | | | | | thousand other things which were (generally inadvertantly) relying on that. llvm-svn: 123814
* Fix warnings found by gcc-4.6, from -Wunused-but-set-variable andJeffrey Yasskin2011-01-181-1/+0
| | | | | | -Wint-to-pointer-cast. llvm-svn: 123719
* Teach template template argument pack expansions to keep track of theDouglas Gregor2011-01-141-2/+6
| | | | | | | number of expansions, when we know it, and propagate that information through Sema. llvm-svn: 123493
* The variable 'ReusedDecl' is written but never read.Ted Kremenek2011-01-141-2/+0
| | | | | | Remove this variable (found by clang static analyzer). llvm-svn: 123484
* The variable 'isTemplateSpecialization' is no longerTed Kremenek2011-01-141-6/+3
| | | | | | used; nuke all assignments and its declaration. llvm-svn: 123483
* Start implementing support for substitution into pack expansions thatDouglas Gregor2011-01-141-0/+5
| | | | | | | | | | | | | | | | | involve template parameter packs at multiple template levels that occur within the signatures members of class templates (and partial specializations thereof). This is a work-in-progress that is deficient in several ways, notably: - It only works for template type parameter packs, but we need to also support non-type template parameter packs and template template parameter packs. - It doesn't keep track of the lengths of the substituted argument packs in the expansion, so it can't properly diagnose length mismatches. However, this is a concrete step in the right direction. llvm-svn: 123425
* Only apply the parameter pack matching of C++0x [temp.arg.template]p3Douglas Gregor2011-01-131-1/+2
| | | | | | | | | when we're actually matching a template template argument to a template template parameter. Otherwise, use strict matching. Fixes <rdar://problem/8859985> clang++: variadics and out-of-line definitions. llvm-svn: 123385
* Implement C++0x [temp.arg.template]p3, which allows slightly fuzzyDouglas Gregor2011-01-131-23/+76
| | | | | | | | matching of variadic template template parameters to template arguments. This paragraph was the subject of ISO C++ committee document N2555: Extending Variadic Template Template Parameters. llvm-svn: 123348
* Refactor and simplify Sema::TemplateParameterListsAreEqual. We had aDouglas Gregor2011-01-121-133/+106
| | | | | | bunch of duplicated checks for parameter pack/non-pack mismatches. llvm-svn: 123343
* Add TemplateArgument::CreatePackCopy() to create a new parameter packDouglas Gregor2011-01-111-6/+5
| | | | | | | in ASTContext-allocated memory, copying the provided template arguments. Use this new routine where we can. No functionality change. llvm-svn: 123289
* Implement C++ [temp.func.order]p5 more directly, by passing down theDouglas Gregor2011-01-111-2/+2
| | | | | | | | | number of explicit call arguments. This actually fixes an erroneous test for [temp.deduct.partial]p11, where we were considering parameters corresponding to arguments beyond those that were explicitly provided. llvm-svn: 123244
* Work-in-progress implementation of C++0x [temp.arg.explicit]p9, whichDouglas Gregor2011-01-101-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | allows an argument pack determines via explicit specification of function template arguments to be extended by further, deduced arguments. For example: template<class ... Types> void f(Types ... values); void g() { f<int*, float*>(0, 0, 0); // Types is deduced to the sequence int*, float*, int } There are a number of FIXMEs in here that indicate places where we need to implement + test retained expansions, plus a number of other places in deduction where we need to correctly cope with the explicitly-specified arguments when deducing an argument pack. Furthermore, it appears that the RecursiveASTVisitor needs to be auditied; it's missing some traversals (especially w.r.t. template arguments) that cause it not to find unexpanded parameter packs when it should. The good news, however, is that the tr1::tuple implementation now works fully, and the tr1::bind example (both from N2080) is actually working now. llvm-svn: 123163
* Replace the representation of template template argument packDouglas Gregor2011-01-051-1/+15
| | | | | | | | | | | | | expansions with something that is easier to use correctly: a new template argment kind, rather than a bit on an existing kind. Update all of the switch statements that deal with template arguments, fixing a few latent bugs in the process. I"m happy with this representation, now. And, oh look! Template instantiation and deduction work for template template argument pack expansions. llvm-svn: 122896
* Add semantic analysis for the creation of and an AST representationDouglas Gregor2011-01-051-2/+15
| | | | | | | | | | | | | | | | | | | | | for template template argument pack expansions. This allows fun such as: template<template<class> class ...> struct apply_impl { /*...*/ }; template<template<class> class ...Metafunctions> struct apply { typedef typename apply_impl<Metafunctions...>::type type; }; However, neither template argument deduction nor template instantiation is implemented for template template argument packs, so this functionality isn't useful yet. I'll probably replace the encoding of template template argument pack expansions in TemplateArgument so that it's harder to accidentally forget about the expansion. However, this is a step in the right general direction. llvm-svn: 122890
* Update C++ [temp.param]p11 citation to reflect the changes in C++0x. No ↵Douglas Gregor2011-01-051-3/+4
| | | | | | functionality change llvm-svn: 122878
OpenPOWER on IntegriCloud