summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Added locations and type source info for DeclarationName.Abramo Bagnara2010-08-111-23/+26
| | | | llvm-svn: 110860
* Random temporary string cleanup.Benjamin Kramer2010-08-111-1/+1
| | | | llvm-svn: 110807
* Fixed redundant NNS loading.Abramo Bagnara2010-08-101-4/+6
| | | | llvm-svn: 110677
* Template keyword should not be ignored building a QualifiedTemplateName.Abramo Bagnara2010-08-061-3/+5
| | | | llvm-svn: 110441
* Get rid of isObjectType; when C++ says "object type", it generallyEli Friedman2010-08-051-5/+3
| | | | | | | just means "not a function type", not "not a function type or void". This changes behavior slightly, but generally in a way which accepts more code. llvm-svn: 110303
* Don't set out-of-line template specialization/definition informationDouglas Gregor2010-07-281-2/+2
| | | | | | | for AST nodes that aren't actually out-of-line (i.e., require a nested-name-specifier). Fixes <rdar://problem/8204126>. llvm-svn: 109704
* Enable expression transformations in the current-instantiationDouglas Gregor2010-07-281-9/+0
| | | | | | | rebuilder, i.e., remove a silly short-sighted hack from long ago. Thanks to Abramo Bagnara for the test case/bug report! llvm-svn: 109583
* Remove the vast majority of the Destroy methods from the AST library,Douglas Gregor2010-07-251-2/+0
| | | | | | since we aren't going to be calling them ever. llvm-svn: 109377
* Hide the specializations folding sets of ClassTemplateDecl as an ↵Argyrios Kyrtzidis2010-07-201-51/+19
| | | | | | | | | | | | | implementation detail (InsertPos leaks though) and add methods to its interface for adding/finding specializations. Simplifies its users a bit and we no longer need to replace specializations in the folding set with their redeclarations. We just return the most recent redeclarations. As a bonus, it fixes http://llvm.org/PR7670. llvm-svn: 108832
* Update ImplicitCastExpr to be able to represent an XValue.Sebastian Redl2010-07-201-4/+2
| | | | llvm-svn: 108807
* When performing template name lookup for a dependent member accessDouglas Gregor2010-07-161-5/+5
| | | | | | | | | expression such as the "foo" in "this->blah.foo<1, 2>", and we can't look into the type of "this->blah" (e.g., because it is dependent), look into the local scope of a template of the same name. Fixes <rdar://problem/8198511>. llvm-svn: 108531
* When there are extra or missing template parameter lists in a templateDouglas Gregor2010-07-141-3/+16
| | | | | | | | | | definition, we're likely going to end up breaking the invariants of the template system, e.g., that the depths of template parameter lists match up with the nesting template of the template. So, make sure we mark such ill-formed declarations as invalid or don't even build them at all. llvm-svn: 108372
* Provide a special diagnostic for attempts to explicitly specializeDouglas Gregor2010-07-131-6/+16
| | | | | | | | class templates within class scope (which is ill-formed), and recover by dropping the explicit specialization entirely. Fixes the infinite loop in PR7622. llvm-svn: 108217
* When performing substitution of template arguments within the body ofDouglas Gregor2010-07-081-1/+1
| | | | | | | a template, be sure to include the template arguments from the injected-class-name. Fixes PR7587. llvm-svn: 107895
* Correctly set the location of the "template" keyword for a classDouglas Gregor2010-07-061-1/+2
| | | | | | template specialization, from Peter Collingbourne. llvm-svn: 107682
* Implement C++ DR481, which clarifies that the scope of templateDouglas Gregor2010-07-011-107/+65
| | | | | | | | | | | | | | | | | parameters starts at the end of the template-parameter rather than at the point where the template parameter name is encounted. For example, given: typedef unsigned char T; template<typename T = T> struct X0 { }; The "T" in the default argument refers to the typedef of "unsigned char", rather than referring to the newly-introduced template type parameter 'T'. Addresses <rdar://problem/8122812>. llvm-svn: 107354
* When typo correction produces a result that is not of the kind we'reDouglas Gregor2010-06-291-1/+2
| | | | | | | looking for, reset the name within the LookupResult structure in addition to clearing out the results. Fixes PR7508. llvm-svn: 107197
* When we see a 'template' disambiguator that marks the next identifierDouglas Gregor2010-06-161-15/+17
| | | | | | | | | | | (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
* Fix the recently-added warning about 'typename' and 'template'Douglas Gregor2010-06-161-23/+23
| | | | | | | | | disambiguation keywords outside of templates in C++98/03. Previously, the warning would fire when the associated nested-name-specifier was not dependent, but that was a misreading of the C++98/03 standard: now, we complain only when we're outside of any template. llvm-svn: 106161
* Downgrade the error when using a typedef in the nested-name-specifierDouglas Gregor2010-06-161-3/+3
| | | | | | | of an explicit instantiation to an ExtWarn, since nobody else seems to diagnose this problem. llvm-svn: 106109
* Revert r106099; it broke self-host.Douglas Gregor2010-06-161-1/+1
| | | | llvm-svn: 106100
* Added TemplateTypeParmType::getDecl().Abramo Bagnara2010-06-161-1/+1
| | | | llvm-svn: 106099
* Fix a point of semantics with using declaration hiding: method templatesJohn McCall2010-06-161-9/+8
| | | | | | | | | | | | | | | | | introduced by using decls are hidden even if their template parameter lists or return types differ from the "overriding" declaration. Propagate using shadow declarations around more effectively when looking up template-ids. Reperform lookup for template-ids in member expressions so that access control is properly set up. Fix some number of latent bugs involving template-ids with totally invalid base types. You can only actually get these with a scope specifier, since otherwise the template-id won't parse as a template-id. Fixes PR7384. llvm-svn: 106093
* Introduce Type::isIntegralOrEnumerationType(), to cover those placesDouglas Gregor2010-06-161-3/+3
| | | | | | | | | | in C++ that involve both integral and enumeration types. Convert all of the callers to Type::isIntegralType() that are meant to work with both integral and enumeration types over to Type::isIntegralOrEnumerationType(), to prepare to eliminate enumeration types as integral types. llvm-svn: 106071
* Allocate template parameter lists for out-of-line definitions via theDouglas Gregor2010-06-151-3/+4
| | | | | | ASTContext rather than via the normal heap. llvm-svn: 106008
* Warn when a 'typename' or a 'template' keyword refers to aDouglas Gregor2010-06-141-2/+19
| | | | | | | non-dependent type or template name, respectively, in C++98/03. Fixes PR7111 and <rdar://problem/8002682>. llvm-svn: 105968
* TemplateSpecializationType's isCurrentInstantiation bit can be derivedJohn McCall2010-06-131-4/+1
| | | | | | from its canonical type. llvm-svn: 105912
* Added template parameters info for out-of-line definitions of class template ↵Abramo Bagnara2010-06-121-0/+13
| | | | | | methods. llvm-svn: 105882
* Don't omit class explicit instantiation from AST.Abramo Bagnara2010-06-121-50/+69
| | | | llvm-svn: 105880
* Split DependentNameType into two types. DependentNameType represents theJohn McCall2010-06-111-84/+22
| | | | | | | | | | | | | | case of an elaborated-type-specifier like 'typename A<T>::foo', and DependentTemplateSpecializationType represents the case of an elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc representation of a DependentTST conveniently exactly matches that of an ElaboratedType wrapping a TST. Kill off the explicit rebuild methods for RebuildInCurrentInstantiation; the standard implementations work fine because the nested name specifier is computable in the newly-entered context. llvm-svn: 105801
* Added inherited info to template and non-type arguments of templates.Abramo Bagnara2010-06-091-8/+10
| | | | llvm-svn: 105716
* Add an extension to avoid an error when a global template has the same name asJeffrey Yasskin2010-06-051-2/+3
| | | | | | | | | | | | | | | | | | | | a member template, and you try to call the member template with an explicit template argument. See PR7247 For example, this downgrades the error to a warning in: template<typename T> struct set{}; struct Value { template<typename T> void set(T value) { } }; void foo() { Value v; v.set<double>(3.2); // Warning here. } llvm-svn: 105518
* Alter the interface of GetTypeForDeclarator to return a TypeSourceInfo*.John McCall2010-06-041-3/+4
| | | | | | This is never null, but the associated type might be. llvm-svn: 105503
* When checking for equality of template parameter lists, a templateDouglas Gregor2010-06-041-3/+26
| | | | | | type parameter pack is distinct from a template type parameter. llvm-svn: 105464
* Copy source information for the inner type of an elaborated type; fixes someJohn McCall2010-05-281-32/+31
| | | | | | valgrind problems. llvm-svn: 105062
* It turns out that people love using VLAs in templates, too. Weaken ourDouglas Gregor2010-05-231-7/+8
| | | | | | | | VLA restrictions so that one can use VLAs in templates (even accidentally), but not as part of a non-type template parameter (which would be very bad). llvm-svn: 104471
* Provide the overloaded functions for UnresolvedLookupExpr andDouglas Gregor2010-05-231-2/+2
| | | | | | | UnresolvedMemberExpr in their constructors, rather than adding them after the fact. No functionality change. llvm-svn: 104468
* Implement support for variable length arrays in C++. VLAs are limitedDouglas Gregor2010-05-221-4/+14
| | | | | | | | | | | | | in several important ways: - VLAs of non-POD types are not permitted. - VLAs cannot be used in conjunction with C++ templates. These restrictions are intended to keep VLAs out of the parts of the C++ type system where they cause the most trouble. Fixes PR5678 and <rdar://problem/8013618>. llvm-svn: 104443
* Improve recovery when we see a dependent template name that is missingDouglas Gregor2010-05-211-0/+1
| | | | | | | | | | | | | | | the required "template" keyword, using the same heuristics we do for dependent template names in member access expressions, e.g., test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template' keyword to treat 'getAs' as a dependent template name T::getAs<U>(); ^ template Fixes PR5404. llvm-svn: 104409
* Improve parser recovery when we encounter a dependent template nameDouglas Gregor2010-05-211-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
* Added TemplateArgumentListInfo to FunctionTemplateSpecializationInfo.Abramo Bagnara2010-05-201-24/+18
| | | | llvm-svn: 104226
* Renamed misleading getSourceRange -> getLocalSourceRange and ↵Abramo Bagnara2010-05-201-4/+4
| | | | | | getFullSourceRange -> getSourceRange for TypeLoc. llvm-svn: 104220
* Support implicitly closing on 'this' in a block. Fixed PR7165.John McCall2010-05-201-3/+5
| | | | | | (the codegen works here, too, but that's annoying to test without execution) llvm-svn: 104202
* fix the TemplateArgumentList copy constructor to notChris Lattner2010-05-201-1/+1
| | | | | | | be a copy constructor (since it isn't one semantically) and fix the ownership bits it sets to be correct! llvm-svn: 104192
* Added basic source locations to Elaborated and DependentName types.Abramo Bagnara2010-05-191-20/+46
| | | | llvm-svn: 104169
* Revert r103770, "Added basic source locations to Elaborated and DependentNameDaniel Dunbar2010-05-141-40/+10
| | | | | | types.", it is breaking Clang bootstrap. llvm-svn: 103775
* Added basic source locations to Elaborated and DependentName types.Abramo Bagnara2010-05-141-10/+40
| | | | llvm-svn: 103770
* Rework when and how vtables are emitted, by tracking where vtables areDouglas Gregor2010-05-131-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "used" (e.g., we will refer to the vtable in the generated code) and when they are defined (i.e., because we've seen the key function definition). Previously, we were effectively tracking "potential definitions" rather than uses, so we were a bit too eager about emitting vtables for classes without key functions. The new scheme: - For every use of a vtable, Sema calls MarkVTableUsed() to indicate the use. For example, this occurs when calling a virtual member function of the class, defining a constructor of that class type, dynamic_cast'ing from that type to a derived class, casting to/through a virtual base class, etc. - For every definition of a vtable, Sema calls MarkVTableUsed() to indicate the definition. This happens at the end of the translation unit for classes whose key function has been defined (so we can delay computation of the key function; see PR6564), and will also occur with explicit template instantiation definitions. - For every vtable defined/used, we mark all of the virtual member functions of that vtable as defined/used, unless we know that the key function is in another translation unit. This instantiates virtual member functions when needed. - At the end of the translation unit, Sema tells CodeGen (via the ASTConsumer) which vtables must be defined (CodeGen will define them) and which may be used (for which CodeGen will define the vtables lazily). From a language perspective, both the old and the new schemes are permissible: we're allowed to instantiate virtual member functions whenever we want per the standard. However, all other C++ compilers were more lazy than we were, and our eagerness was both a performance issue (we instantiated too much) and a portability problem (we broke Boost test cases, which now pass). Notes: (1) There's a ton of churn in the tests, because the order in which vtables get emitted to IR has changed. I've tried to isolate some of the larger tests from these issues. (2) Some diagnostics related to implicitly-instantiated/implicitly-defined virtual member functions have moved to the point of first use/definition. It's better this way. (3) I could use a review of the places where we MarkVTableUsed, to see if I missed any place where the language effectively requires a vtable. Fixes PR7114 and PR6564. llvm-svn: 103718
* Merged Elaborated and QualifiedName types.Abramo Bagnara2010-05-111-47/+31
| | | | llvm-svn: 103517
* The C++98/03 standard is disturbingly silent about out-of-scopeDouglas Gregor2010-05-111-3/+12
| | | | | | | | | | explicit instantiations of template. C++0x clarifies the intent (they're ill-formed in some cases; see [temp.explicit] for details). However, one could squint at the C++98/03 standard and conclude they are permitted, so reduce the error to a warning (controlled by -Wc++0x-compat) in C++98/03 mode. llvm-svn: 103482
OpenPOWER on IntegriCloud