summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* remove unneeded llvm:: namespace qualifiers on some core types now that ↵Chris Lattner2011-07-231-14/+14
| | | | | | | | LLVM.h imports them into the clang namespace. llvm-svn: 135852
* Restore the C-style cast hack for enum template arguments,John McCall2011-07-151-1/+10
| | | | | | | | which is required given the current setup for template argument deduction substitution validation, and add a test case to make sure we don't break it in the future. llvm-svn: 135262
* Create a new expression node, SubstNonTypeTemplateParmExpr,John McCall2011-07-151-30/+24
| | | | | | | | to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
* Random cleanup:Francois Pichet2011-07-081-8/+7
| | | | | | | - fix a comment. - Remove an unnecessary { } block. llvm-svn: 134690
* Introduce the notion of instantiation dependence into Clang's AST. ADouglas Gregor2011-07-011-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | type/expression/template argument/etc. is instantiation-dependent if it somehow involves a template parameter, even if it doesn't meet the requirements for the more common kinds of dependence (dependent type, type-dependent expression, value-dependent expression). When we see an instantiation-dependent type, we know we always need to perform substitution into that instantiation-dependent type. This keeps us from short-circuiting evaluation in places where we shouldn't, and lets us properly implement C++0x [temp.type]p2. In theory, this would also allow us to properly mangle instantiation-dependent-but-not-dependent decltype types per the Itanium C++ ABI, but we aren't quite there because we still mangle based on the canonical type in cases like, e.g., template<unsigned> struct A { }; template<typename T> void f(A<sizeof(sizeof(decltype(T() + T())))>) { } template void f<int>(A<sizeof(sizeof(int))>); and therefore get the wrong answer. llvm-svn: 134225
* Preserve that a TemplateName was arrived at by substitutingJohn McCall2011-06-301-1/+2
| | | | | | | | | | | for a template template parameter. Uses to follow. I've also made the uniquing of SubstTemplateTemplateParmPacks use a ContextualFoldingSet as a minor space efficiency. llvm-svn: 134137
* Add support for C++ namespace-aware typo correction, e.g., correctingDouglas Gregor2011-06-281-10/+15
| | | | | | | | | | | | | | | vector<int> to std::vector<int> Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes PR5776/<rdar://problem/8652971>. Thanks Kaelyn! llvm-svn: 134007
* Objective-ARC++: infer template type arguments ofDouglas Gregor2011-06-171-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ownership-unqualified retainable object type as __strong. This allows us to write, e.g., std::vector<id> and we'll infer that the vector's element types have __strong ownership semantics, which is far nicer than requiring: std::vector<__strong id> Note that we allow one to override the ownership qualifier of a substituted template type parameter, e.g., given template<typename T> struct X { typedef __weak T type; }; X<id> is treated the same as X<__strong id>. At instantiation type, the __weak in "__weak T" overrides the (inferred or specified) __strong on the template argument type, so that we can still provide metaprogramming transformations. This is part of <rdar://problem/9595486>. llvm-svn: 133303
* Automatic Reference Counting.John McCall2011-06-151-4/+11
| | | | | | | | | | Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
* When performing substitution of default template template parametersDouglas Gregor2011-06-151-10/+0
| | | | | | | | | | before the template parameters have acquired a proper context (e.g., because the enclosing context has yet to be built), provide empty parameter lists for all outer template parameter scopes to inhibit any substitution for those template parameters. Fixes PR9643 / <rdar://problem/9251019>. llvm-svn: 133055
* Made changes to how 'struct'/'class' mismatches are handled in ↵Richard Trieu2011-06-101-4/+6
| | | | | | | | | | | | | | | | | -Wmismatched-tags. - Removed fix-it hints from template instaniations since changes to the templates are rarely helpful. - Changed the caret in template instaniations from the class/struct name to the class/struct keyword, matching the other warnings. - Do not offer fix-it hints when multiple declarations disagree. Warnings are still given. - Once a definition is found, offer a fix-it hint to all previous declarations with wrong tag. - Declarations that disagree with a previous definition will get a fix-it hint to change the declaration. llvm-svn: 132831
* Diagnose the condition in C++ [temp.expl.spec]p16 that prohibitsDouglas Gregor2011-06-061-0/+37
| | | | | | | specializing a member of an unspecialized template, and recover from such errors without crashing. Fixes PR10024 / <rdar://problem/9509761>. llvm-svn: 132677
* Revert r132544. Accidental commit. I got confused with the Tortoise SVN menu.Francois Pichet2011-06-031-2/+0
| | | | llvm-svn: 132546
* (no commit message)Francois Pichet2011-06-031-0/+2
| | | | llvm-svn: 132544
* When checking the instantiation of a default template argument againstDouglas Gregor2011-06-031-9/+14
| | | | | | | | | | | | | | | the template parameter, perform the checking as a "specified" template argument rather than a "deduced" template argument; the latter implies stricter type checking that is not permitted for default template arguments. Also, cleanup our handling of substitution of explicit template arguments for a function template. We were actually performing some substitution of default arguments at this point! Fixes PR10069. llvm-svn: 132529
* Fix an incorrect warning about explicit template specializations forDouglas Gregor2011-06-011-1/+1
| | | | | | nested types, from Michael Han! llvm-svn: 132431
* Objective-C doesn't consider the use of incomplete types as methodDouglas Gregor2011-05-271-0/+10
| | | | | | | | | | | | | | parameter types to be ill-formed. However, it relies on the completeness of method parameter types when producing metadata, e.g., for a protocol, leading IR generating to crash in such cases. Since there's no real way to tighten down the semantics of Objective-C here without breaking existing code, do something safe but lame: suppress the generation of metadata when this happens. Fixes <rdar://problem/9123036>. llvm-svn: 132171
* Implement a new type node, UnaryTransformType, designed to represent aAlexis Hunt2011-05-241-0/+5
| | | | | | | | type that turns one type into another. This is used as the basis to implement __underlying_type properly - with TypeSourceInfo and proper behavior in the face of templates. llvm-svn: 132017
* Audit and finish the implementation of C++0x nullptr, fixing twoDouglas Gregor2011-05-211-5/+17
| | | | | | | | | | | | | | minor issues along the way: - Non-type template parameters of type 'std::nullptr_t' were not permitted. - We didn't properly introduce built-in operators for nullptr ==, !=, <, <=, >=, or > as candidate functions . To my knowledge, there's only one (minor but annoying) part of nullptr that hasn't been implemented: catching a thrown 'nullptr' as a pointer or pointer-to-member, per C++0x [except.handle]p4. llvm-svn: 131813
* Diagnose the presence of storage-class-specifiers on explicitDouglas Gregor2011-05-211-3/+13
| | | | | | instantiations and specializations. Fixes <rdar://problem/9126453> and PR8700. llvm-svn: 131802
* Introduce Type::isSignedIntegerOrEnumerationType() andDouglas Gregor2011-05-201-4/+4
| | | | | | | | | | | | | Type::isUnsignedIntegerOrEnumerationType(), which are like Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also consider the underlying type of a C++0x scoped enumeration type. Audited all callers to the existing functions, switching those that need to also handle scoped enumeration types (e.g., those that deal with constant values) over to the new functions. Fixes PR9923 / <rdar://problem/9447851>. llvm-svn: 131735
* When checking a set of template parameter lists against aDouglas Gregor2011-05-151-2/+7
| | | | | | | | | nested-name-specifier, re-evaluate the nested-name-specifier as if we were entering that context (which we did!), so that we'll resolve a template-id to a particular class template partial specialization. Fixes PR9913. llvm-svn: 131383
* Revert 131347. It asserts if the specialization in within a class template:Francois Pichet2011-05-141-6/+3
| | | | | | | | | | | | template<class U> struct X1 { template<class T> void f(T*); template<> void f(int*) { } }; Won't be so simple. I need to think more about it. llvm-svn: 131362
* In Microsoft mode, allow template function explicit specialization at class ↵Francois Pichet2011-05-141-3/+6
| | | | | | | | | | | | | | scope. Necessary to parse MFC and MSVC standard lib code. Example: struct X { template<class T> void f(T) { } template<> void f(int) { } } llvm-svn: 131347
* PR9908: Fix the broken fix for PR9902 to get the template argument lists in ↵Richard Smith2011-05-141-1/+1
| | | | | | | | the right order. Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers. llvm-svn: 131342
* Teach the template parameter dependency checker used when matchingDouglas Gregor2011-05-131-0/+4
| | | | | | | | template parameter lists to scope specifiers for friend declarations about injected class name types. Fixes the g++.dg/template/memfriend5.C regression in the GCC testsuite. llvm-svn: 131272
* Fix PR9902: correctly substitute alias templates within the template in ↵Richard Smith2011-05-121-0/+3
| | | | | | which they are defined: provide an empty list of arguments for each containing template context during substitution. llvm-svn: 131211
* When checking for the necessary 'template<>' headers based on theDouglas Gregor2011-05-111-4/+10
| | | | | | | | | | nested of an out-of-line declaration, only require a 'template<>' header for each enclosing class template that hasn't been previously specialized; previously, we were requiring 'template<>' for enclosing class templates and members of class templates that hadn't been previously specialized. Fixes <rdar://problem/9422013>. llvm-svn: 131207
* Reimplement Sema::MatchTemplateParametersToScopeSpecifier() based onDouglas Gregor2011-05-101-147/+273
| | | | | | | | | | | | | | | | | | the semantic context referenced by the nested-name-specifier rather than the syntactic form of the nested-name-specifier. The previous incarnation was based on my complete misunderstanding of C++ [temp.expl.spec]. The latest C++0x working draft clarifies the requirements here, and this rewrite is intended to follow that. Along the way, improve source location information in the diagnostics. For example, if we report that a specific type needs or doesn't need a 'template<>' header, we dig out that type in the nested-name-specifier and highlight its range. Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and <rdar://problem/9135379>. llvm-svn: 131138
* Implement support for C++0x alias templates.Richard Smith2011-05-051-19/+65
| | | | llvm-svn: 130953
* When converting an integral template argument value to a non-typeDouglas Gregor2011-05-041-15/+22
| | | | | | | template parameter of type 'bool', force the value to be zero or one. Fixes <rdar://problem/9169404>. llvm-svn: 130873
* 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
OpenPOWER on IntegriCloud