Commit Graph

1209 Commits

Author SHA1 Message Date
Douglas Gregor f4f296de01 Template instantiation for the declarations of member functions within
a class template. At present, we can only instantiation normal
methods, but not constructors, destructors, or conversion operators.

As ever, this contains a bit of refactoring in Sema's type-checking. In
particular:

  - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator
    (handling the declarator itself) and CheckFunctionDeclaration
    (checking for the the function declaration), the latter of which
    is also used by template instantiation.
  - We were performing the adjustment of function parameter types in
    three places; collect those into a single new routine.
  - When the type of a parameter is adjusted, allocate an
    OriginalParmVarDecl to keep track of the type as it was written.
  - Eliminate a redundant check for out-of-line declarations of member
    functions; hide more C++-specific checks on function declarations
    behind if(getLangOptions().CPlusPlus).

llvm-svn: 67575
2009-03-23 23:06:20 +00:00
Douglas Gregor 90a1a65194 Introduce a new expression type, UnresolvedDeclRefExpr, that describes
dependent qualified-ids such as

  Fibonacci<N - 1>::value

where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.

Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.

We can now process a simple Fibonacci computation described as a
template metaprogram.

llvm-svn: 67308
2009-03-19 17:26:29 +00:00
Douglas Gregor 975e6d0ccd Print the context of tag types as part of pretty-printing, e.g.,
struct N::M::foo

llvm-svn: 67284
2009-03-19 04:25:59 +00:00
Douglas Gregor e177b7254d Extend the use of QualifiedNameType to the creation of class template
specialization names. This way, we keep track of sugared types like

  std::vector<Real>

I believe we are now using QualifiedNameTypes everywhere we can. Next
step: QualifiedDeclRefExprs.

llvm-svn: 67268
2009-03-19 00:39:20 +00:00
Douglas Gregor 5253768ada Introduce a representation for types that we referred to via a
qualified name, e.g., 

  foo::x

so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.

The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
 
  ::foo::bar::x

The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled). 

The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).

Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.

llvm-svn: 67265
2009-03-19 00:18:19 +00:00
Gabor Greif 7b5243a1fc added type dependent testcase
llvm-svn: 67230
2009-03-18 20:26:44 +00:00
Gabor Greif 68cfd78375 cleanup instantiation code, tighten testcase
llvm-svn: 67148
2009-03-18 01:16:08 +00:00
Gabor Greif 8af7837b08 instantiate ?: expressions
llvm-svn: 67145
2009-03-18 00:55:04 +00:00
Douglas Gregor 45418cb4a9 Small sanity-checking testcase
llvm-svn: 67133
2009-03-17 23:49:44 +00:00
Douglas Gregor 954f6b27da Implement instantiation of enums within class templates. This isn't
quite as great as it sounds, because, while we can refer to the
enumerator values outside the template, e.g.,

  adder<long, 3, 4>::value

we can't yet refer to them with dependent names, so no Fibonacci
(yet). 

InstantiateClassTemplateSpecialization is getting messy; next commit
will put it into a less-ugly state.

llvm-svn: 67092
2009-03-17 19:05:46 +00:00
Anders Carlsson 5bd30395b9 (Hopefully) instantiate dependent array types correctly.
llvm-svn: 67032
2009-03-15 20:12:13 +00:00
Douglas Gregor 52aba87df7 Check for overflow and signedness problems with template
arguments. Eliminates a FIXME.

llvm-svn: 66993
2009-03-14 00:20:21 +00:00
Douglas Gregor 084d855a17 Implement template instantiation for the prefix unary operators. As
always, refactored the existing logic to tease apart the parser action
and the semantic analysis shared by the parser and template
instantiation.

llvm-svn: 66987
2009-03-13 23:49:33 +00:00
Douglas Gregor 4b7f3d7344 Devious test-case involved overload resolution and ADL during template instantiation.
llvm-svn: 66951
2009-03-13 21:04:12 +00:00
Douglas Gregor 0950e41b73 Implement template instantiation for several more kinds of expressions:
- 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
2009-03-13 21:01:28 +00:00
Douglas Gregor 6873f9c521 Implement template instantiation for builtin binary operators
llvm-svn: 66835
2009-03-12 22:46:12 +00:00
Douglas Gregor 573c7467df Straw man for instantiation of expressions. Use it to instantiate the
width of bitfields. 

I'll be burning this down and replacing it with a properly-dispatched
implementation like the one used for types.

llvm-svn: 66796
2009-03-12 16:53:44 +00:00
Douglas Gregor 04e9a03e6f Fix various problems with matching out-of-line definitions of static
class members to the corresponding in-class declaration.

Diagnose the erroneous use of 'static' on out-of-line definitions of
class members. 

llvm-svn: 66740
2009-03-11 23:52:16 +00:00
Douglas Gregor 1efa437be6 Implement basic template instantiation for fields. Reshuffle checking
for FieldDecls so that the parser and the template instantiation make
use of the same semantic checking module.

llvm-svn: 66685
2009-03-11 18:59:21 +00:00
Douglas Gregor 2689746705 Add basic, hackish support for instantiation of typedefs in a class
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?

llvm-svn: 66662
2009-03-11 16:48:53 +00:00
Douglas Gregor 79cf603428 Extend the notion of active template instantiations to include the
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
2009-03-10 20:44:00 +00:00
Douglas Gregor 2a72edd413 If we run into multiple errors within the same template instantiation,
only print the template instantiation backtrace for the first error.

Also, if a base class has failed to type-check during instantiation,
just drop that base class and continue on to check other base classes.

llvm-svn: 66563
2009-03-10 18:52:44 +00:00
Douglas Gregor 65b2c4c381 Add pretty-printing for class template specializations, e.g.,
'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
2009-03-10 18:33:27 +00:00
Douglas Gregor 4ea568f213 Add a notion of "post-diagnostic hooks", which are callbacks attached
to a diagnostic that will be invoked after the diagnostic (if it is
not suppressed). The hooks are allowed to produce additional
diagnostics (typically notes) that provide more information. We should
be able to use this to help diagnostic clients link notes back to the
diagnostic they clarify. Comments welcome; I'll write up documentation
and convert other clients (e.g., overload resolution failures) if
there are no screams of protest.

As the first client of post-diagnostic hooks, we now produce a
template instantiation backtrace when a failure occurs during template
instantiation. There's still more work to do to make this output
pretty, if that's even possible.

llvm-svn: 66557
2009-03-10 18:03:33 +00:00
Douglas Gregor fcd5db3bfa Limit the template instantiation depth to some user-configurable value
(default: 99). Beyond this limit, produce an error and consider the
current template instantiation a failure.

The stack we're building to track the instantiations will, eventually,
be used to produce instantiation backtraces from diagnostics within
template instantiation. However, we're not quite there yet.

This adds a new Clang driver option -ftemplate-depth=NNN, which should
eventually be generated from the GCC command-line operation
-ftemplate-depth-NNN (note the '-' rather than the '='!). I did not
make the driver changes to do this mapping.

llvm-svn: 66513
2009-03-10 00:06:19 +00:00
Douglas Gregor d9c90a7317 Add a test case that goes with the last commit
llvm-svn: 66510
2009-03-09 23:48:53 +00:00
Douglas Gregor c40290e452 Implement template instantiation for ClassTemplateSpecializationTypes,
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
2009-03-09 23:48:35 +00:00
Douglas Gregor 463421deb1 Implement the basics of implicit instantiation of class templates, in
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
2009-03-03 04:44:36 +00:00
Douglas Gregor 6eaaf30968 Template instantiation for function types
llvm-svn: 65668
2009-02-28 01:04:19 +00:00
Douglas Gregor 17c0d7bacf Implement template instantiation for pointer, reference, and (some)
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
2009-02-28 00:25:32 +00:00
Douglas Gregor fe1e11092e Implement the basic approach for instantiating types, with a lot of FIXME'd
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
2009-02-27 19:31:52 +00:00
Douglas Gregor 87f95b0a6a Introduce code modification hints into the diagnostics system. When we
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
2009-02-26 21:00:50 +00:00
Sebastian Redl 8d2ccae28b Make more AST nodes and semantic checkers dependent-expression-aware.
llvm-svn: 65529
2009-02-26 14:39:58 +00:00
Douglas Gregor 8d0921617e Use RecordFirst/RecordLast range checks in DeclContext
llvm-svn: 65489
2009-02-26 00:02:51 +00:00
Douglas Gregor d54dfb8718 Implementing parsing of template-ids as class-names, so that we can
derive from a class template specialization, e.g.,

  class B : public A<int> { };

llvm-svn: 65488
2009-02-25 23:52:28 +00:00
Douglas Gregor cbb45d0c65 Cope with use of the token '>>' inside a template argument list, e.g.,
vector<vector<double>> Matrix;

In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.

In C++0x, this token is always broken into two '>' tokens.

llvm-svn: 65484
2009-02-25 23:02:36 +00:00
Douglas Gregor 1e249f8641 Improve location information on "reused" class template specialization
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
2009-02-25 22:18:32 +00:00
Douglas Gregor f47b911f6e Perform additional semantic checking of class template
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
2009-02-25 22:02:03 +00:00
Douglas Gregor 441f24118a Include the appropriate header for malloc
llvm-svn: 65471
2009-02-25 19:48:02 +00:00
Douglas Gregor 7f74112756 Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
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
2009-02-25 19:37:18 +00:00
Chris Lattner 810d330cd3 Fix a long standard problem with clang retaining "too much" sugar
information about types.  We often print diagnostics where we say 
"foo_t" is bad, but the user doesn't know how foo_t is declared 
(because it is a typedef).  Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).

Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
 MAX(P, F);
 ^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B)    ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                             ^

After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
 MAX(P, F);
 ^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B)    ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                             ^

llvm-svn: 65081
2009-02-19 23:45:49 +00:00
Douglas Gregor 0f3dd9a86b Provide a proper source location when building an implicit dereference. Fixes PR3600
llvm-svn: 64993
2009-02-19 00:52:42 +00:00
Douglas Gregor 67a6564091 Implement basic parsing and semantic analysis for explicit
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
2009-02-17 23:15:12 +00:00
Douglas Gregor 264ec4f237 Added ClassTemplateSpecializationDecl, which is a subclass of
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
2009-02-17 01:05:43 +00:00
Douglas Gregor ccb0776288 Finished semantic analysis of non-type template arguments, to check
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
2009-02-11 19:52:55 +00:00
Douglas Gregor f8f868336e Allow the use of default template arguments when forming a class
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
2009-02-11 18:16:40 +00:00
Douglas Gregor 0e55853639 Implement semantic checking for template arguments that correspond to
pointer-to-member-data non-type template parameters. Also, get
consistent about what it means to returned a bool from
CheckTemplateArgument.

llvm-svn: 64305
2009-02-11 16:16:59 +00:00
Douglas Gregor 6f233ef1d8 Add semantic checking for template arguments that correspond to
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
2009-02-11 01:18:59 +00:00
Douglas Gregor a9faa44162 Semantic checking for template arguments that correspond to non-type
template parameters that have reference type. Effectively, we're doing
a very limited form of reference binding here.

llvm-svn: 64270
2009-02-11 00:44:29 +00:00
Douglas Gregor 3a7796bccc Add partial semantic checking of template arguments that are meant for
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
2009-02-11 00:19:33 +00:00
Douglas Gregor 86560404fc Add type-checking and implicit conversions for template parameters of
integral or enumeration type.

llvm-svn: 64256
2009-02-10 23:36:10 +00:00
Douglas Gregor 85e8b3eeed Fix a problem with bogus template shadowing warnings
llvm-svn: 64230
2009-02-10 19:52:54 +00:00
Douglas Gregor dba326363c Implement parsing, semantic analysis and ASTs for default template
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
2009-02-10 19:49:53 +00:00
Douglas Gregor 8133879c5e Semantic analysis for non-type template parameter declarations.
llvm-svn: 64223
2009-02-10 17:43:50 +00:00
Douglas Gregor 97f34576d4 Teach the type-id/expression disambiguator about different
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
2009-02-10 00:53:15 +00:00
Douglas Gregor 85e0f66250 Check template template arguments against their corresponding template
template parameters.

llvm-svn: 64188
2009-02-10 00:24:35 +00:00
Douglas Gregor d32e028f79 Rudimentary checking of template arguments against their corresponding
template parameters when performing semantic analysis of a template-id
naming a class template specialization.

llvm-svn: 64185
2009-02-09 23:23:08 +00:00
Douglas Gregor 8bf4205c70 Start processing template-ids as types when the template-name refers
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
2009-02-09 18:46:07 +00:00
Douglas Gregor cd72ba97e7 Semantic checking for class template declarations and
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
2009-02-06 22:42:48 +00:00