summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Make sure that the canonical representation of integral template arguments ↵Douglas Gregor2009-03-141-4/+5
| | | | | | uses the bitwidth and signedness of the template parameter llvm-svn: 66990
* Implement template instantiation for several more kinds of expressions:Douglas Gregor2009-03-131-1/+8
| | | | | | | | | | | | - C++ function casts, e.g., T(foo) - sizeof(), alignof() More importantly, this allows us to verify that we're performing overload resolution during template instantiation, with argument-dependent lookup and the "cached" results of name lookup from the template definition. llvm-svn: 66947
* Store the type of the integral value within a TemplateArgument, so that we ↵Douglas Gregor2009-03-121-1/+2
| | | | | | can more efficiently reconstruct an IntegerLiteral from it during template instantiation llvm-svn: 66833
* Extend the notion of active template instantiations to include theDouglas Gregor2009-03-101-1/+11
| | | | | | | | | | | | context of a template-id for which we need to instantiate default template arguments. In the TextDiagnosticPrinter, don't suppress the caret diagnostic if we are producing a non-note diagnostic that follows a note diagnostic with the same location, because notes are (conceptually) a part of the warning or error that comes before them. llvm-svn: 66572
* Add pretty-printing for class template specializations, e.g.,Douglas Gregor2009-03-101-1/+2
| | | | | | | | | | | | | | | | 'struct A<double, int>' In the "template instantiation depth exceeded" message, print "-ftemplate-depth-N" rather than "-ftemplate-depth=N". An unnamed tag type that is declared with a typedef, e.g., typedef struct { int x, y; } Point; can be used as a template argument. Allow this, and check that we get sensible pretty-printing for such things. llvm-svn: 66560
* Implement template instantiation for ClassTemplateSpecializationTypes,Douglas Gregor2009-03-091-111/+195
| | | | | | | | | | | | | | | | | | | | | | such as replacing 'T' in vector<T>. There are a few aspects to this: - Extend TemplateArgument to allow arbitrary expressions (an Expr*), and switch ClassTemplateSpecializationType to store TemplateArguments rather than it's own type-or-expression representation. - ClassTemplateSpecializationType can now store dependent types. In that case, the canonical type is another ClassTemplateSpecializationType (with default template arguments expanded) rather than a declaration (we don't build Decls for dependent types). - Split ActOnClassTemplateId into ActOnClassTemplateId (called from the parser) and CheckClassTemplateId (called from ActOnClassTemplateId and InstantiateType). They're smart enough to handle dependent types, now. llvm-svn: 66509
* Mark a non-type template parameter invalid if there was a problem with its typeDouglas Gregor2009-03-091-1/+3
| | | | llvm-svn: 66422
* Implement the basics of implicit instantiation of class templates, inDouglas Gregor2009-03-031-44/+81
| | | | | | | | | | | | | | | | | | | | response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
* Implement template instantiation for pointer, reference, and (some)Douglas Gregor2009-02-281-1/+1
| | | | | | | | | | | | | array types. Semantic checking for the construction of these types has been factored out of GetTypeForDeclarator and into separate subroutines (BuildPointerType, BuildReferenceType, BuildArrayType). We'll be doing the same thing for all other types (and declarations and expressions). As part of this, moved the type-instantiation functions into a class in an anonymous namespace. llvm-svn: 65663
* Implement the basic approach for instantiating types, with a lot of FIXME'dDouglas Gregor2009-02-271-2/+13
| | | | | | | | | | | stubs for those types we don't yet know how to instantiate (everything that isn't a template parameter!). We now instantiate default arguments for template type parameters when needed. This will be our testbed while I fill out the remaining type-instantiation logic. llvm-svn: 65649
* Clean up and document code modification hints.Douglas Gregor2009-02-271-1/+1
| | | | llvm-svn: 65641
* Make the type associated with a ClassTemplateSpecializationDecl be aDouglas Gregor2009-02-261-2/+14
| | | | | | | | nicely sugared type that shows how the user wrote the actual specialization. This sugared type won't actually show up until we start doing instantiations. llvm-svn: 65577
* Introduce code modification hints into the diagnostics system. When weDouglas Gregor2009-02-261-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). llvm-svn: 65570
* Improve location information on "reused" class template specializationDouglas Gregor2009-02-251-6/+16
| | | | | | | | decls. Test and document the semantic location of class template specialization definitions that occur within a scope enclosing the scope of the class template. llvm-svn: 65478
* Perform additional semantic checking of class templateDouglas Gregor2009-02-251-11/+102
| | | | | | | | | | | | specializations. In particular: - Make sure class template specializations have a "template<>" header, and complain if they don't. - Make sure class template specializations are declared/defined within a valid context. (e.g., you can't declare a specialization std::vector<MyType> in the global namespace). llvm-svn: 65476
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* silence some warnings in no asserts mode.Chris Lattner2009-02-201-5/+4
| | | | llvm-svn: 65169
* Downgrade complaints about calling unavailable functions to a warningDouglas Gregor2009-02-181-0/+3
| | | | | | | | | | | | | | | | | | (as GCC does), except when we've performed overload resolution and found an unavailable function: in this case, we actually error. Merge the checking of unavailable functions with the checking for deprecated functions. This unifies a bit of code, and makes sure that we're checking for unavailable functions in the right places. Also, this check can cause an error. We may, eventually, want an option to make "unavailable" warnings into errors. Implement much of the logic needed for C++0x deleted functions, which are effectively the same as "unavailable" functions (but always cause an error when referenced). However, we don't have the syntax to specify deleted functions yet :) llvm-svn: 64955
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-13/+145
| | | | | | | | | | | | | | | | | | specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
* Added ClassTemplateSpecializationDecl, which is a subclass ofDouglas Gregor2009-02-171-24/+152
| | | | | | | | | | | | | | | | | | CXXRecordDecl that is used to represent class template specializations. These are canonical declarations that can refer to either an actual class template specialization in the code, e.g., template<> class vector<bool> { }; or to a template instantiation. However, neither of these features is actually implemented yet, so really we're just using (and uniqing) the declarations to make sure that, e.g., A<int> is a different type from A<float>. Note that we carefully distinguish between what the user wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it represents (e.g., "A<float, int>"); the former is in the sugared Type, the latter is an actual Decl. llvm-svn: 64716
* Fix comment.Mike Stump2009-02-111-1/+1
| | | | llvm-svn: 64337
* Appease the language lawyersDouglas Gregor2009-02-111-1/+1
| | | | llvm-svn: 64321
* Finished semantic analysis of non-type template arguments, to checkDouglas Gregor2009-02-111-15/+167
| | | | | | | | | | | for non-external names whose address becomes the template argument. This completes C++ [temp.arg.nontype]p1. Note that our interpretation of C++ [temp.arg.nontype]p1b3 differs from EDG's interpretation (we're stricter, and GCC agrees with us). They're opening a core issue about the matter. llvm-svn: 64317
* Avoid bogus warning.Mike Stump2009-02-111-1/+2
| | | | llvm-svn: 64313
* Reverted r64307. Moved hasSameType and hasSameUnqualifiedType fromDouglas Gregor2009-02-111-5/+5
| | | | | | Sema to ASTContext. llvm-svn: 64312
* Allow the use of default template arguments when forming a classDouglas Gregor2009-02-111-2/+3
| | | | | | | | | | | | | | template specialization (e.g., std::vector<int> would now be well-formed, since it relies on a default argument for the Allocator template parameter). This is much less interesting than one might expect, since (1) we're not actually using the default arguments for anything important, such as naming an actual Decl, and (2) we'll often need to instantiate the default arguments to check their well-formedness. The real fun will come later. llvm-svn: 64310
* Rename Sema::hasSameType to QualType::isSameAsDouglas Gregor2009-02-111-5/+5
| | | | | | Rename Sema::hasSameUnqualifiedType to QualType::isSameIgnoringQalifiers llvm-svn: 64307
* Implement semantic checking for template arguments that correspond toDouglas Gregor2009-02-111-6/+24
| | | | | | | | pointer-to-member-data non-type template parameters. Also, get consistent about what it means to returned a bool from CheckTemplateArgument. llvm-svn: 64305
* Add semantic checking for template arguments that correspond toDouglas Gregor2009-02-111-73/+90
| | | | | | | | | | | | | | non-type template parameters that are references to functions or pointers to member functions. Did a little bit of refactoring so that these two cases, along with the handling of non-type template parameters that are pointers to functions, are handled by the same path. Also, tweaked FixOverloadedFunctionReference to cope with member function pointers. This is a necessary step for getting all of the fun member pointer conversions working outside of template arguments, too. llvm-svn: 64277
* Semantic checking for template arguments that correspond to non-typeDouglas Gregor2009-02-111-3/+40
| | | | | | | template parameters that have reference type. Effectively, we're doing a very limited form of reference binding here. llvm-svn: 64270
* Add partial semantic checking of template arguments that are meant forDouglas Gregor2009-02-111-3/+69
| | | | | | | | | | | | | | | | | | | non-type template parameters of pointer-to-object and pointer-to-function type. The most fun part of this is the use of overload resolution to pick a function from the set of overloaded functions that comes in as a template argument. Also, fixed two minor bugs in this area: - We were allowing non-type template parameters of type pointer to void. - We weren't patching up an expression that refers to an overloaded function set via "&f" properly. We're still not performing complete checking of the expression to be sure that it is referring to an object or function with external linkage (C++ [temp.arg.nontype]p1). llvm-svn: 64266
* Add type-checking and implicit conversions for template parameters ofDouglas Gregor2009-02-101-1/+69
| | | | | | integral or enumeration type. llvm-svn: 64256
* Implement parsing, semantic analysis and ASTs for default templateDouglas Gregor2009-02-101-0/+248
| | | | | | | | | arguments. This commit covers checking and merging default template arguments from previous declarations, but it does not cover the actual use of default template arguments when naming class template specializations. llvm-svn: 64229
* Semantic analysis for non-type template parameter declarations.Douglas Gregor2009-02-101-0/+35
| | | | llvm-svn: 64223
* Teach the type-id/expression disambiguator about differentDouglas Gregor2009-02-101-2/+2
| | | | | | | | | | | | | | | | | disambiguation contexts, so that we properly parse template arguments such as A<int()> as type-ids rather than as expressions. Since this can be confusing (especially when the template parameter is a non-type template parameter), we try to give a friendly error message. Almost, eliminate a redundant error message (that should have been a note) and add some ultra-basic checks for non-type template arguments. llvm-svn: 64189
* Check template template arguments against their corresponding templateDouglas Gregor2009-02-101-12/+66
| | | | | | template parameters. llvm-svn: 64188
* Rudimentary checking of template arguments against their correspondingDouglas Gregor2009-02-091-0/+182
| | | | | | | template parameters when performing semantic analysis of a template-id naming a class template specialization. llvm-svn: 64185
* Eliminate TemplateArg so that we only have a single kind ofDouglas Gregor2009-02-091-34/+9
| | | | | | | | | | | | representation for template arguments. Also simplifies the interface for ActOnClassTemplateSpecialization and eliminates some annoying allocations of TemplateArgs. My attempt at smart pointers for template arguments lists is relatively lame. We can improve it once we're sure that we have the right representation for template arguments. llvm-svn: 64154
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-091-19/+69
| | | | | | | | | | | | | | | | | | | | | to a class template. For example, the template-id 'vector<int>' now has a nice, sugary type in the type system. What we can do now: - Parse template-ids like 'vector<int>' (where 'vector' names a class template) and form proper types for them in the type system. - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly, using (sadly) a bool in the parser to tell it whether '>' should be treated as an operator or not. This is a baby-step, with major problems and limitations: - There are currently two ways that we handle template arguments (whether they are types or expressions). These will be merged, and, most likely, TemplateArg will disappear. - We don't have any notion of the declaration of class template specializations or of template instantiations, so all template-ids are fancy names for 'int' :) llvm-svn: 64153
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-2/+267
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-041-7/+63
| | | | llvm-svn: 63750
* Some name-lookup-related fixes, from Piotr Rak!Douglas Gregor2009-02-041-3/+3
| | | | | | | | | | | | | - Changes Lookup*Name functions to return NamedDecls, instead of Decls. Unfortunately my recent statement that it will simplify lot of code, was not quite right, but it simplifies some... - Makes MergeLookupResult SmallPtrSet instead of vector, following Douglas suggestions. - Adds %qN format for printing qualified names to Diagnostic. - Avoids searching for using-directives in Scopes, which are not DeclScope, during unqualified name lookup. llvm-svn: 63739
* Eliminated LookupCriteria, whose creation was causing a bottleneck forDouglas Gregor2009-01-301-5/+3
| | | | | | | | | | | | | | | | | | LookupName et al. Instead, use an enum and a bool to describe its contents. Optimized the C/Objective-C path through LookupName, eliminating any unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing some code and arguments that are no longer used. Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers over to LookupName, LookupQualifiedName, or LookupParsedName, as appropriate. All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and -disable-free. Plus, we're down to three name-lookup routines. llvm-svn: 63354
* Refactor Sema::LookupDecl() into 2 functions: LookupDeclInScope() and ↵Steve Naroff2009-01-291-3/+6
| | | | | | | | | | LookupDeclInContext(). The previous interface was very confusing. This is much more explicit, which will be easier to understand/optimize/convert. The plan is to eventually deprecate both of these functions. For now, I'm focused on performance. llvm-svn: 63256
* Keep track of template arguments when we parse them. Right now, we don't ↵Douglas Gregor2008-12-241-2/+20
| | | | | | actually do anything with the template arguments, but they'll be used to create template declarations llvm-svn: 61413
* Ultrasimplistic sketch for the parsing of C++ template-ids. This won'tDouglas Gregor2008-12-181-0/+36
| | | | | | | | become useful or correct until we (1) parse template arguments correctly, (2) have some way to turn template-ids into types, declarators, etc., and (3) have a real representation of templates. llvm-svn: 61208
* Move Sema::isTemplateParameterDecl to Decl::isTemplateParameter, where it ↵Douglas Gregor2008-12-081-9/+3
| | | | | | belongs llvm-svn: 60708
* Introduce basic support for dependent types, type-dependentDouglas Gregor2008-12-051-0/+1
| | | | | | | | | | | | expressions, and value-dependent expressions. This permits us to parse some template definitions. This is not a complete solution; we're missing type- and value-dependent computations for most of the expression types, and we're missing checks for dependent types and type-dependent expressions throughout Sema. llvm-svn: 60615
* Representation of template type parameters and non-type templateDouglas Gregor2008-12-051-0/+116
parameters, with some semantic analysis: - Template parameters are introduced into template parameter scope - Complain about template parameter shadowing (except in Microsoft mode) Note that we leak template parameter declarations like crazy, a problem we'll remedy once we actually create proper declarations for templates. Next up: dependent types and value-dependent/type-dependent expressions. llvm-svn: 60597
OpenPOWER on IntegriCloud