Commit Graph

349 Commits

Author SHA1 Message Date
David Blaikie 7afed5e5bf PR12710 - broken default argument handling for templates.
I broke this in r155838 by not actually instantiating non-dependent default arg
expressions. The motivation for that change was to avoid producing duplicate
conversion warnings for such default args (we produce them once when we parse
the template - there's no need to produce them at each instantiation) but
without actually instantiating the default arg, things break in weird ways.

Technically, I think we could still get the right diagnostic experience without
the bugs if we instantiated the non-dependent args (for non-dependent params
only) immediately, rather than lazily. But I'm not sure if such a refactoring/
change would be desirable so here's the conservative fix for now.

llvm-svn: 155893
2012-05-01 06:05:57 +00:00
David Blaikie f68e809c5e Fix PR12378: provide conversion warnings on default args of function templates
Apparently we weren't checking default arguments when they were instantiated.
This adds the check, fixes the lack of instantiation caching (which seems like
it was mostly implemented but just missed the last step), and avoids
implementing non-dependent default args (for non-dependent parameter types) as
uninstantiated default arguments (so that we don't warn once for every
instantiation when it's not instantiation dependent).

Reviewed by Richard Smith.

llvm-svn: 155838
2012-04-30 18:21:31 +00:00
Richard Smith 72249ba945 PR12647: An alias template instantiation which occurs in a SFINAE context is
itself a SFINAE context.

llvm-svn: 155621
2012-04-26 07:24:08 +00:00
Richard Smith f623c96260 Implement DR1330 in C++11 mode, to support libstdc++4.7 which uses it.
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.

When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.

Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.

Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.

This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.

llvm-svn: 154886
2012-04-17 00:58:00 +00:00
Douglas Gregor 3024f07c12 Implement C++11 [expr.prim.general]p3, which permits the use of 'this'
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type. 

The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.

Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.

Fixes PR10036 and PR12450.

llvm-svn: 154799
2012-04-16 07:05:22 +00:00
Douglas Gregor 31f55dced5 Implement support for null non-type template arguments for non-type
template parameters of pointer, pointer-to-member, or nullptr_t
type in C++11. Fixes PR9700 / <rdar://problem/11193097>.

llvm-svn: 154219
2012-04-06 22:40:38 +00:00
Richard Smith b66d77793f When defining a forward-declared enum, don't try to attach the definition to
a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.

llvm-svn: 153349
2012-03-23 23:09:08 +00:00
Richard Smith 7d137e3b98 Support for definitions of member enumerations of class templates outside the
class template's definition, and for explicit specializations of such enum
members.

llvm-svn: 153304
2012-03-23 03:33:32 +00:00
Richard Smith 4b38ded66a Instantiating a class template should not instantiate the definition of any
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.

llvm-svn: 152750
2012-03-14 23:13:10 +00:00
David Blaikie bbafb8a745 Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536
2012-03-11 07:00:24 +00:00
Douglas Gregor 0c46b2b7ce Introduce support for template instantiation of lambda
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:

  - Added new entry points for TreeTransform, so that we can
  explicitly establish the link between the lambda closure type in the
  template and the lambda closure type in the instantiation.
  - Added a bit into LambdaExpr specifying whether it had an explicit
  result type or not. We should have had this anyway.

This code is 'lightly' tested.

llvm-svn: 150417
2012-02-13 22:00:16 +00:00
Sebastian Redl a935179ab7 Represent C++ direct initializers as ParenListExprs before semantic analysis
instead of having a special-purpose function.

- ActOnCXXDirectInitializer, which was mostly duplication of
  AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
  ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
  int x = {1};
  int x({1});
  int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
   initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
  always produces a ParenListExpr. Placed that so far failed to convert that
  back to a ParenExpr containing comma operators have been fixed. I'm pretty
  sure I could have made a crashing test case before this.

The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)

This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.

llvm-svn: 150318
2012-02-11 23:51:47 +00:00
Argyrios Kyrtzidis e378948c8a For class template implicit instantiation, also update its location to point
to the pattern template that it came from, otherwise we had this situation:

template <typename T1, typename T2>
struct S {
};

template <typename T>
struct S<T, int> {
};

void f() {
  S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>"
}

llvm-svn: 150290
2012-02-11 01:59:57 +00:00
Benjamin Kramer bf8da9d706 Move instantiateTemplateAttribute into the sema namespace, make helpers static.
llvm-svn: 149864
2012-02-06 11:13:08 +00:00
Douglas Gregor 0dd22bc4d6 When we're substituting into a function parameter pack and expect to
get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.

llvm-svn: 148960
2012-01-25 16:15:54 +00:00
Richard Smith 928be491e0 Fix PR11848: decree that an alias template contains an unexpanded parameter pack
iff its substitution contains an unexpanded parameter pack. This has the effect
that we now reject declarations such as this (which we used to crash when
expanding):

  template<typename T> using Int = int;
  template<typename ...Ts> void f(Int<Ts> ...ints);

The standard is inconsistent on how this case should be treated.

llvm-svn: 148905
2012-01-25 02:14:59 +00:00
DeLesley Hutchins 30398dd410 Delayed template instantiation of late-parsed attributes.
llvm-svn: 148595
2012-01-20 22:50:54 +00:00
David Blaikie 8a40f700e6 Remove unreachable code in Clang. (replace with llvm_unreachable where appropriate or when GCC requires it)
llvm-svn: 148292
2012-01-17 06:56:22 +00:00
Douglas Gregor ec9fd13c77 De-virtualize getPreviousDecl() and getMostRecentDecl() when we know
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).

Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.

llvm-svn: 148187
2012-01-14 16:38:05 +00:00
Nico Weber 3ffc4c93fd Fix a crash on invalid, http://llvm.org/pr11599
llvm-svn: 146988
2011-12-20 20:32:49 +00:00
Abramo Bagnara 12dcbf3eaa Fixed implicit instantiations source range.
llvm-svn: 144977
2011-11-18 08:08:52 +00:00
Abramo Bagnara fd3a455ac7 Fixed source range for template implicit instantiations.
llvm-svn: 141018
2011-10-03 20:34:03 +00:00
Douglas Gregor 75acd925d0 Only print _Bool as 'bool' when 'bool' is defined as an object-like
macro whose only replacement token is '_Bool'.

llvm-svn: 140656
2011-09-27 23:30:47 +00:00
Douglas Gregor c0b07286cf When 'bool' is not a built-in type but is defined as a macro, print
'bool' rather than '_Bool' within types, to make things a bit more
readable. Fixes <rdar://problem/10063263>.

llvm-svn: 140650
2011-09-27 22:38:19 +00:00
David Blaikie 751c558d8e ArrayRef-ifying the fields passed to Sema::ActOnFields
llvm-svn: 140293
2011-09-22 02:58:26 +00:00
David Blaikie b9c168a265 ArrayRef-ifying the UnexpandedParameterPacks passed to Sema::CheckParameterPacksForExpansion
llvm-svn: 140290
2011-09-22 02:34:54 +00:00
Francois Pichet 00c7e6ceb1 Implement function template specialization at class scope extension in Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
Example:
template <class T>
class A {
public:
  template <class U> void f(U p) {  }
  template <> void f(int p) {  } // <== class scope specialization
};

This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.

llvm-svn: 137573
2011-08-14 03:52:19 +00:00
Chris Lattner 0e62c1cc0b remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports
them into the clang namespace.

llvm-svn: 135852
2011-07-23 10:55:15 +00:00
Richard Smith e3daab2449 Replace r134583's fix for PR10290 with one which also works for non-value-dependent cases.
llvm-svn: 135543
2011-07-20 00:12:52 +00:00
John McCall 7c454bb8ce Create a new expression node, SubstNonTypeTemplateParmExpr,
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
2011-07-15 05:09:51 +00:00
Nick Lewycky 365efd62a1 In an in-class initialization, defer checks for value-dependent initialization
expressions.

llvm-svn: 134583
2011-07-07 02:20:13 +00:00
Douglas Gregor 678d76c026 Introduce the notion of instantiation dependence into Clang's AST. A
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
2011-07-01 01:22:09 +00:00
John McCall d9dfe3a1f8 Preserve that a TemplateName was arrived at by substituting
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
2011-06-30 08:33:18 +00:00
Douglas Gregor 55462626b6 When performing substitution of default template template parameters
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
2011-06-15 14:20:42 +00:00
Richard Smith 938f40b5aa Implement support for C++11 in-class initialization of non-static data members.
llvm-svn: 132878
2011-06-11 17:19:42 +00:00
Richard Trieu caa33d36fb Made changes to how 'struct'/'class' mismatches are handled in -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
2011-06-10 03:11:26 +00:00
Douglas Gregor a51c9ccf2d Add an assertion to tell us when we're going off the deep end trying
to determine outer template arguments lists for template
parameters. This is actually the problem behind PR9643, which I have
yet to figure out how to fix.

llvm-svn: 131822
2011-05-22 00:21:10 +00:00
Douglas Gregor a7203e537d When determining whether we need to instantiate a function type,
also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.

llvm-svn: 131099
2011-05-09 20:45:16 +00:00
Alexis Hunt 4a8ea1092a Modify some deleted function methods to better reflect reality:
- New isDefined() function checks for deletedness
 - isThisDeclarationADefinition checks for deletedness
 - New doesThisDeclarationHaveABody() does what
   isThisDeclarationADefinition() used to do
 - The IsDeleted bit is not propagated across redeclarations
 - isDeleted() now checks the canoncial declaration
 - New isDeletedAsWritten() does what it says on the tin.
 - isUserProvided() now correct (thanks Richard!)

This fixes the bug that we weren't catching

void foo() = delete;
void foo() {}

as being a redefinition.

llvm-svn: 131013
2011-05-06 20:44:56 +00:00
Richard Smith 3f1b5d077b Implement support for C++0x alias templates.
llvm-svn: 130953
2011-05-05 21:57:07 +00:00
John McCall 8fb0d9d24a Store a parameter index and function prototype depth in every
parameter node and use this to correctly mangle parameter
references in function template signatures.

A follow-up patch will improve the storage usage of these
fields;  here I've just done the lazy thing.

llvm-svn: 130669
2011-05-01 22:35:37 +00:00
Chandler Carruth 0883632acb Re-applies the patch first applied way back in r106099, with
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
2011-05-01 00:51:33 +00:00
John McCall 5476666d17 Diagnose attempts to implicitly instantiate a template before it is
fully defined.  Somehow this escaped notice for a very long time.

llvm-svn: 130298
2011-04-27 06:46:31 +00:00
Abramo Bagnara dff1930bf7 Fixed source range for all DeclaratorDecl's.
llvm-svn: 127225
2011-03-08 08:55:46 +00:00
Douglas Gregor 9d9f8db4bc When substituting in for a template name, do not produce a qualified
template name as the result of substitution. The qualifier is handled
separately by the tree transformer, so we would end up in an
inconsistent state.

This is actually the last bit of PR9016, and possibly also fixes
PR8965. It takes Boost.Icl from "epic fail" down to a single failure.

llvm-svn: 127108
2011-03-05 20:06:51 +00:00
Douglas Gregor 43669f84ed When determining template instantiation arguments within a function
template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.

Fixes PR9016.

llvm-svn: 127092
2011-03-05 17:54:25 +00:00
Douglas Gregor fd35cde35e Kill off TreeTransform::TransformNestedNameSpecifier() in favor of the
source-location-preserving
TreeTransform::TranformNestedNameSpecifierLoc(). No functionality
change: the victim had no callers (that themselves had callers) anyway.

llvm-svn: 126853
2011-03-02 18:50:38 +00:00
Douglas Gregor df846d11c1 Kill off the TreeTransform::TransformTemplateName overload that has
poor source-location information.

llvm-svn: 126852
2011-03-02 18:46:51 +00:00
Douglas Gregor 9db535035d Start migrating TreeTransform's TransformTemplateName over to version
that preserve source-location information. This commit adds more
redundancy than it removes; WIP.

llvm-svn: 126849
2011-03-02 18:07:45 +00:00
Douglas Gregor c52264e719 When we're substituting into a parameter-type-list nested inside the pattern
of an expansion, and we have a paramameter that is not a parameter
pack, don't suppress substitution of parameter packs within this
context.

llvm-svn: 126819
2011-03-02 02:04:06 +00:00