Commit Graph

969 Commits

Author SHA1 Message Date
Richard Smith 34349003cf PR13136:
* When substituting a reference to a non-type template parameter pack where the
   corresponding argument is a pack expansion, transform into an expression
   which contains an unexpanded parameter pack rather than into an expression
   which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
   to be inside the PackExpansionExpr, rather than outside, so the expression
   still looks like a pack expansion and can be deduced.

 * Teach MarkUsedTemplateParameters that we can deduce a reference to a template
   parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
   added during alias template substitution).

llvm-svn: 159922
2012-07-09 03:07:20 +00:00
Richard Smith d636ce5ec1 Halve template depth in an attempt to get this test passing on mingw32.
llvm-svn: 159917
2012-07-08 21:06:29 +00:00
NAKAMURA Takumi c30cc99411 test/SemaTemplate/instantiation-depth-defarg.cpp: Mark as XFAIL:mingw for now.
I'll try to increase stack size later.

llvm-svn: 159912
2012-07-08 09:35:16 +00:00
Richard Smith 7ebb07c87c PR13243: When deducing a non-type template parameter which is specified as an
expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.

llvm-svn: 159909
2012-07-08 04:37:51 +00:00
Richard Smith 8a874c93d9 PR9793: Treat substitution as an instantiation step for the purpose of the
-ftemplate-depth limit.  There are various ways to get an infinite (or merely
huge) stack of substitutions with no intervening instantiations. This is also
consistent with gcc's behavior.

llvm-svn: 159907
2012-07-08 02:38:24 +00:00
Richard Smith 4ff9ff974c When marking virtual functions as used for a class' vtable, mark all functions
which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.

llvm-svn: 159895
2012-07-07 06:59:51 +00:00
Nico Weber 7b5a716f3d Make explicit specializations at class scope work
for non-type template parameters in microsoft mode.
PR12709.

llvm-svn: 159147
2012-06-25 17:21:05 +00:00
Nico Weber 3c10fb1d8e Show fixit for unqualified calls to methods of dependent bases
when the calling site is a member function template.

Effectively reverts r111675.

llvm-svn: 159004
2012-06-22 16:39:39 +00:00
Nico Weber df7dffb34b Allow unqualified lookup of non-dependent member functions
in microsoft mode. Fixes PR12701.

The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.

llvm-svn: 158842
2012-06-20 20:21:42 +00:00
Richard Smith 2b013185f8 PR13064: Store whether an in-class initializer uses direct or copy
initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288
2012-06-10 03:12:00 +00:00
Kaelyn Uhrain 055e9479eb Fix up the 'typename' suggestion logic introduced in r157085, based on
feedback from Doug Gregor.

llvm-svn: 158185
2012-06-08 01:07:26 +00:00
Simon Atanasyan d45982cb00 Replace inline asm constraint "=a" by the more general constraint "=r".
That extend a range of platforms support this test case.

llvm-svn: 157247
2012-05-22 11:03:10 +00:00
Eli Friedman a9e9ebcfb5 Make delegating initializers use a similar codepath to base initializers in dependent contexts. PR12890.
llvm-svn: 157136
2012-05-19 23:35:23 +00:00
Kaelyn Uhrain 864d0b002c Suggest adding 'typename' when it would make the compiler
accept the template argument expression as a type.

llvm-svn: 157085
2012-05-18 23:42:49 +00:00
David Blaikie 7555b6a4e5 Improve some of the conversion warnings to fire on conversion to bool.
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.

Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.

llvm-svn: 156826
2012-05-15 16:56:36 +00:00
Richard Smith 45855df4c6 Recover properly if a class member declaration starts with a scope specifier
or template-id which can't be parsed.

llvm-svn: 156468
2012-05-09 08:23:23 +00:00
Richard Smith 6f8d2c6c9c A little tweak to the SFINAE condition reporting. Don't say:
candidate template ignored: substitution failed [with T = int]: no type named 'type' in 'std::enable_if<false, void>'

Instead, just say:

  candidate template ignored: disabled by 'enable_if' [with T = int]

... and point at the enable_if condition which (we assume) failed.

This is applied to all cases where the user writes 'typename enable_if<...>::type' (optionally prefixed with a nested name specifier), and 'enable_if<...>' names a complete class type which does not have a member named 'type', and this results in a candidate function being ignored in a SFINAE context. Thus it catches 'std::enable_if', 'std::__1::enable_if', 'boost::enable_if' and 'llvm::enable_if'.

llvm-svn: 156463
2012-05-09 05:17:00 +00:00
Richard Smith 9ca6461f5a When we suppress an error due to SFINAE, stash the diagnostic away with the
overload candidate, and include its message in any subsequent 'candidate not
viable due to substitution failure' note we may produce.

To keep the note small (since the 'overload resolution failed' diagnostics are
often already very verbose), the text of the SFINAE diagnostic is included as
part of the text of the note, and any notes which were attached to it are
discarded.

There happened to be spare space in OverloadCandidate into which a
PartialDiagnosticAt could be squeezed, and this patch goes to lengths to avoid
unnecessary PartialDiagnostic copies, resulting in no slowdown that I could
measure. (Removal in passing of some PartialDiagnostic copies has resulted in a
slightly smaller clang binary overall.) Even on a torture test, I was unable to
measure a memory increase of above 0.2%.

llvm-svn: 156297
2012-05-07 09:03:25 +00:00
David Blaikie afd3d0ba40 Fix test cases broken by 155936.
llvm-svn: 155948
2012-05-01 21:29:03 +00:00
Eli Friedman c25372bb76 Add a missing ExpressionEvaluationContext for template default arguments. Fixes PR12581.
llvm-svn: 155670
2012-04-26 22:43:24 +00:00
Argyrios Kyrtzidis 6fe744cc38 When resolving default template arguments, it should be done in the declaration context
of the template what we are going to instantiate.

Fixes various crashes of rdar://11242625 & http://llvm.org/PR11421.

llvm-svn: 155576
2012-04-25 18:39:17 +00:00
Richard Smith e85e176600 PR12585: When processing a friend template inside a class template, don't
pretend there was no previous declaration -- that can lead us to injecting
a class template (with no access specifier) into a class scope. Instead,
just avoid the problematic checks.

llvm-svn: 155303
2012-04-22 02:13:50 +00:00
Richard Smith 9f2a7b2e08 Fix test failure.
llvm-svn: 155271
2012-04-21 01:51:32 +00:00
Richard Smith 6483d22f1b When declaring a template, check that the context doesn't already contain a
declaration of the same name. r155187 caused us to miss this if the prior
declaration did not declare a type.

llvm-svn: 155269
2012-04-21 01:27:54 +00:00
Richard Smith 61e582f6bc Replace r155185 with a better fix, which also addresses PR12557. When looking
up an elaborated type specifier in a friend declaration, only look for type
declarations, per [basic.lookup.elab]p2. If we know that the redeclaration
lookup for a friend class template in a dependent context finds a non-template,
don't delay the diagnostic to instantiation time.

llvm-svn: 155187
2012-04-20 07:12:26 +00:00
Richard Smith a7f57e3aca Fix a bug which creduce found reducing PR12585.
llvm-svn: 155185
2012-04-20 05:42:36 +00:00
Patrick Beard 0caa39474b Implements boxed expressions for Objective-C. <rdar://problem/10194391>
llvm-svn: 155082
2012-04-19 00:25:12 +00:00
Richard Smith d372942d77 PR 12586: Fix assert while running libc++ testsuite: deal with exception
specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.

llvm-svn: 155076
2012-04-19 00:08:28 +00:00
Richard Smith 79a52e5709 PR12569: Instantiate exception specifications of explicit instantiations
and explicit specializations of function templates appropriately.

llvm-svn: 154956
2012-04-17 22:30:01 +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
David Blaikie 09ffc9b473 Enable warn_impcast_literal_float_to_integer by default.
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.

The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.

It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").

llvm-svn: 154068
2012-04-05 00:16:44 +00:00
Richard Smith d9a1cd8dbf PR12438: Profile a reference to a type template parameter by depth and index,
not by canonical decl. This only matters for sizeof...(Pack) expressions; in
all other cases, we'd profile it as a type instead.

llvm-svn: 153884
2012-04-02 18:53:24 +00:00
Douglas Gregor 67daacbdc2 If we encounter a friend class template for which we cannot resolve
the nested-name-specifier (e.g., because it is dependent), do not
error even though we can't represent it in the AST at this point.

This is a horrible, horrible hack. The actual feature we still need to
implement (for C++98!) is covered by PR12292. However, we used to
silently accept this code, so when we recently started rejecting it we
caused some regressions (e.g., <rdar://problem/11147355>). This hack
brings us back to the passable-but-not-good state we had previously.

llvm-svn: 153752
2012-03-30 16:20:47 +00:00
Richard Smith 0b472d86de During the instantiation of a class template specialization, that
specialization is known to be incomplete. If we're asked to try to
complete it, don't attempt to instantiate it again -- that can lead
to stack overflow, and to rejects-valids if the class being incomplete
is not an error.

llvm-svn: 153236
2012-03-22 03:35:28 +00:00
Douglas Gregor d17dfe1638 Replace a FIXME with a diagnostic when we can't resolve the
nested-name-specifier for a class template declaration. Fixes PR12291.

llvm-svn: 153006
2012-03-18 00:15:42 +00:00
Richard Smith c5b0552055 Fix parsing of type-specifier-seq's. Types are syntactically allowed to be
defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.

llvm-svn: 152549
2012-03-12 07:56:15 +00:00
Eli Friedman 9b2ab81a0c Correct test from r152189.
llvm-svn: 152191
2012-03-07 01:13:38 +00:00
Eli Friedman 205a429891 Make sure we consistently canonicalize types when canonicalizing TemplateTemplateParmDecls. PR12179.
llvm-svn: 152189
2012-03-07 01:09:33 +00:00
Richard Smith 35ecb36fcd Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.

llvm-svn: 151881
2012-03-02 04:14:40 +00:00
Eli Friedman e4f22dfa95 A couple minor bug-fixes for template instantiation for expressions which are sometimes potentially evaluated.
llvm-svn: 151707
2012-02-29 04:03:55 +00:00
Eli Friedman 59e41d046e Shift Microsoft enum extensions from -fms-extensions to -fms-compatibility, so -fms-extensions doesn't affect enum semantics in incompatible ways. <rdar://problem/10657186>.
llvm-svn: 150663
2012-02-16 05:20:44 +00:00
Richard Smith d3cf238e26 If a static data member of a class template which could be used in a constant
expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.

llvm-svn: 150560
2012-02-15 02:42:50 +00:00
Richard Smith 4a941e25f2 If a constexpr function template specialization is referenced, and then the
template is defined, and then the specialization is referenced again, don't
forget to instantiate the template on the second reference. Use the source
location of the first reference as the point of instantiation, though.

llvm-svn: 150518
2012-02-14 22:25:15 +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
Richard Smith 5e580292ac Track whether a function type has a trailing return type as type sugar. Use this
to pretty-print such function types better, and to fix a case where we were not
instantiating templates in lexical order. In passing, move the Variadic bit from
Type's bitfields to FunctionProtoType to get the Type bitfields down to 32 bits.
Also ensure that we always substitute the return type of a function when
substituting explicitly-specified arguments, since that can cause us to bail
out with a SFINAE error before we hit a hard error in parameter substitution.

llvm-svn: 150241
2012-02-10 09:58:53 +00:00
Richard Smith 25a01eca11 --lies.
llvm-svn: 150240
2012-02-10 09:37:07 +00:00
Eli Friedman edb6f5dca1 Make sure we convert struct layout pragmas to attributes for class templates the same way we do for non-template classes. <rdar://problem/10791194>.
llvm-svn: 150221
2012-02-10 02:02:21 +00:00
Abramo Bagnara 65f7c3dba2 Fixed instantiation of DependentScopeDeclRefExpr.
llvm-svn: 149868
2012-02-06 14:31:00 +00:00
Abramo Bagnara 365591575d Added tests for template keyword presence.
llvm-svn: 149177
2012-01-28 11:04:22 +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
Douglas Gregor 3ecbc3d655 Promote the extension warning for attempts to catch a reference or
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.

llvm-svn: 148838
2012-01-24 19:01:26 +00:00
Richard Smith 2ec4061e39 Pedantic diagnostic correction: in C++, we have integral constant expressions,
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.

llvm-svn: 148209
2012-01-15 03:51:30 +00:00
Richard Smith 69f90dce49 PR10828: Produce a warning when a no-arguments function is declared in block
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.

Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.

Add a new warning group -Wvexing-parse containing both of these warnings.

The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.

llvm-svn: 147599
2012-01-05 04:12:21 +00:00
Richard Smith e434590bd9 Change the diagnostics which said 'accepted as an extension' to instead say
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.

llvm-svn: 147357
2011-12-29 21:57:33 +00:00
Argyrios Kyrtzidis 2644063ec9 Pass context and access to Parser::ParseExplicitInstantiation() for
good parser error recovery and for not crashing.

We still have a accepts-invalid-code bug.

llvm-svn: 147216
2011-12-23 02:16:45 +00:00
Richard Smith ed2974f3cf C++ constant expression handling: eagerly instantiate static const integral data
members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.

llvm-svn: 147023
2011-12-21 00:25:33 +00:00
Richard Trieu 553b2b2e5d Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared.  If either is a substring of the other, then
no error is given.  This gives rise to an unexpected case:

  // expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

  candidate function has different number of parameters (expected 1 but has 2)
  candidate function has different number of parameters

It will also match these other error messages:

  candidate function
  function has different number of parameters
  number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting.  Also, all the failing tests from this
change have been corrected.  Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619
2011-12-15 00:38:15 +00:00
Francois Pichet 025131601d Implement the Microsoft __if_exists/if_not_exists extension in initializer-list.
Necessary to parse Microsoft ATL code.

Example: 
  int array[] = {
    0, 
    __if_exists(CLASS::Type) {2, }
    3
  };

will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.

llvm-svn: 146447
2011-12-12 23:24:39 +00:00
David Blaikie 10eb4b67d8 Add notes for suppressing and (if it's a zero-arg function returning bool) fixing the function-to-bool conversion warning.
llvm-svn: 146280
2011-12-09 21:42:37 +00:00
Lang Hames df5c121f8e Add a warning for implicit conversion from function literals (and static
methods) to bool. E.g.

void foo() {}
if (f) { ... // <- Warns here.
}

Only applies to non-weak functions, and does not apply if the function address
is taken explicitly with the addr-of operator.

llvm-svn: 145849
2011-12-05 20:49:50 +00:00
Francois Pichet 9c39113fdb In Microsoft mode, don't perform typo correction in a template member function dependent context because it interferes with the "lookup into dependent bases of class templates" feature.
Basically typo correction will try to offer a correction instead of looking into type dependent base classes.

I found this problem while parsing Microsoft ATL code with clang.

llvm-svn: 145772
2011-12-03 15:55:29 +00:00
Francois Pichet de232cb166 In Microsoft mode, make "Unqualified lookup into dependent bases of class templates" works inside a friend function definition at class scope.
Basically we have to look into the parent *lexical* DeclContext for friend functions at class scope. That's because calling GetParent() return the namespace or file DeclContext.

This fixes all remaining cases of "Unqualified lookup into dependent bases of class templates" when parsing MFC code with clang.

llvm-svn: 145127
2011-11-25 01:10:54 +00:00
Richard Smith 9a56882e53 Add driver arguments -ftemplate-depth=N and -fconstexpr-depth=N, with the same
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.

Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.

The -ftemplate-depth=N part of this fixes PR9890.

llvm-svn: 145045
2011-11-21 19:36:32 +00:00
Francois Pichet 857f9d6e5e In Microsoft mode, make "Unqualified lookup into dependent bases of class templates" works inside default argument instantiation.
This is a little bit tricky because during default argument instantiation the CurContext points to a CXXMethodDecl but we can't use the keyword this or have an implicit member call generated.

This fixes 2 errors when parsing MFC code with clang.

llvm-svn: 144881
2011-11-17 03:44:24 +00:00
Francois Pichet 78286b24fd In Microsoft mode, make "Unqualified lookup into dependent bases of class templates" works inside static functions.
llvm-svn: 144729
2011-11-15 23:33:34 +00:00
Douglas Gregor 0201a4c2d3 When we're checking access in a dependent context, don't try to look
at the bases of an undefined class. Fixes <rdar://problem/10438657>.

llvm-svn: 144582
2011-11-14 23:00:43 +00:00
Francois Pichet f707ae6733 Move "Unqualified lookup into dependent bases of class templates" Microsoft specific behavior from -fms-extensions to -fms-compatibility.
llvm-svn: 144341
2011-11-11 00:12:11 +00:00
Douglas Gregor 6ea1d665a7 Mark the overloaded atomic builtins as having custom type checking,
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.

llvm-svn: 144110
2011-11-08 19:45:38 +00:00
Douglas Gregor 4109afa1f1 Drastically simplify the mapping from the declaration corresponding to
the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.

This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case). 

Fixes <rdar://problem/9676205>.

Reinstated, now that we have the fix in r143967.

llvm-svn: 143968
2011-11-07 17:43:18 +00:00
Douglas Gregor df593fbeda Tighten up the conditions under which we consider ourselves to be
entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.

llvm-svn: 143967
2011-11-07 17:33:42 +00:00
Devang Patel 2ccf84e3a5 Revert r143551. It is causing g++.dg/template/crash52.C test failure.
llvm-svn: 143725
2011-11-04 18:52:43 +00:00
Douglas Gregor 8f5653a999 Drastically simplify the mapping from the declaration corresponding to
the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.

This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case). 

Fixes <rdar://problem/9676205>.

llvm-svn: 143551
2011-11-02 17:38:53 +00:00
Douglas Gregor fe0055e6c8 When we see an out-of-line definition of a member class template that
does not match any declaration in the class (or class template), be
sure to mark it as invalid. Fixes PR10924 / <rdar://problem/10119422>.

llvm-svn: 143504
2011-11-01 21:35:16 +00:00
Douglas Gregor d73f3ddb44 Rework the AST for the initializer of a delegating constructor, so
that it retains source location information for the type. Aside from
general goodness (being able to walk the types described in that
information), we now have a proper representation for dependent
delegating constructors. Fixes PR10457 (for real).

llvm-svn: 143410
2011-11-01 01:16:03 +00:00
Richard Smith ae1bab56d9 Fix crash due to missing array-to-pointer decay when instantiating an unresolved
member expression. Refactoring to follow.

llvm-svn: 143017
2011-10-26 06:49:26 +00:00
Douglas Gregor 4a2a8f7fb8 Check for unexpanded parameter packs in the name that guards a
Microsoft __if_exists/__if_not_exists statement. Also note that we
weren't traversing DeclarationNameInfo *at all* within the
RecursiveASTVisitor, which would be rather fatal for variadic
templates.

llvm-svn: 142906
2011-10-25 03:44:56 +00:00
Douglas Gregor deb4a2be67 Implement support for dependent Microsoft __if_exists/__if_not_exists
statements. As noted in the documentation for the AST node, the
semantics of __if_exists/__if_not_exists are somewhat different from
the way Visual C++ implements them, because our parsed-template
representation can't accommodate VC++ semantics without serious
contortions. Hopefully this implementation is "good enough".

llvm-svn: 142901
2011-10-25 01:33:02 +00:00
Douglas Gregor 43edb32f1f Rework Microsoft __if_exists/__if_not_exists parsing and semantic
analysis to separate dependent names from non-dependent names. For
dependent names, we'll behave differently from Visual C++:

  - For __if_exists/__if_not_exists at class scope, we'll just warn
    and then ignore them.
  - For __if_exists/__if_not_exists in statements, we'll treat the
    inner statement as a compound statement, which we only instantiate
    in templates where the dependent name (after instantiation)
    exists. This behavior is different from VC++, but it's as close as
    we can get without encroaching ridiculousness.

The latter part (dependent statements) is not yet implemented.

llvm-svn: 142864
2011-10-24 22:31:10 +00:00
Douglas Gregor fbf8752597 When performing name lookup for the previous declaration of a field,
be sure to consider all of the possible lookup results. We were
assert()'ing (but behaving correctly) for unresolved values. Fixes
PR11134 / <rdar://problem/10290422>.

llvm-svn: 142652
2011-10-21 15:47:52 +00:00
Douglas Gregor 44e5a0a72b Diagnose class template (partial) specializations that occur in the
*wrong* class scope. This is one of the problems behind
<rdar://problem/9676205>.

llvm-svn: 142588
2011-10-20 16:41:18 +00:00
Douglas Gregor f65d8ffca7 When we parse something that looks like a templated friend tag but
actually just has an extraneous 'template<>' header, strip off the
'template<>' header and treat it as a normal friend tag. Fixes PR10660
/ <rdar://problem/9958322>.

llvm-svn: 142587
2011-10-20 15:58:54 +00:00
David Blaikie cc5f8f0d9e Switch to the C++11 warning flags in tests.
Patch by Ahmed Charles!

llvm-svn: 142340
2011-10-18 05:54:07 +00:00
Douglas Gregor f333f8c40d When transforming the arguments for a C++ "new" expression, make sure
to drop the implicitly-generated value initialization expression used
for initializing scalars. Fixes <rdar://problem/10283928>.

llvm-svn: 142330
2011-10-18 02:43:19 +00:00
Richard Smith 050d261ec7 Refactor the checking for explicit template instantiations being performed in
the right namespace in C++11 mode. Teach the code to prefer the 'must be in
precisely this namespace' diagnostic whenever that's true, and fix a defect
which resulted in the -Wc++11-compat warning in C++98 mode sometimes being
omitted.

llvm-svn: 142329
2011-10-18 02:28:33 +00:00
Douglas Gregor 041b084f73 When declaring an out-of-line template, attempt to rebuild any types
within the template parameter list that may have changed now that we
know the current instantiation. Fixes <rdar://problem/10194295>.

llvm-svn: 141954
2011-10-14 15:31:12 +00:00
Richard Smith 9ca5c42582 Update all tests other than Driver/std.cpp to use -std=c++11 rather than
-std=c++0x. Patch by Ahmed Charles!

llvm-svn: 141900
2011-10-13 22:29:44 +00:00
Douglas Gregor ebcfbb5d22 When we determine that a function template specialization produced as
part of template argument deduction is ill-formed, we mark it as
invalid and treat it as a deduction failure. If we happen to find that
specialization again, treat it as a deduction failure rather than
silently building a call to the declaration.

Fixes PR11117, a marvelous bug where deduction failed after creating
an invalid specialization, causing overload resolution to pick a
different candidate. Then we performed a similar overload resolution
later, and happily picked the invalid specialization to
call... resulting in a silent link failure.

llvm-svn: 141809
2011-10-12 20:35:48 +00:00
Douglas Gregor 205d044552 Switch diagnostic text from "C++0x" over to "C++11".
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.

llvm-svn: 141801
2011-10-12 19:26:40 +00:00
John McCall 50a2c2c19d Catch placeholder types in DefaultLvalueConversion
and DefaultFunctionArrayLvalueConversion.  To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately.  Harden the build-a-call
logic while we're at it.

llvm-svn: 141738
2011-10-11 23:14:30 +00:00
Douglas Gregor f892c7fe60 For the various CF and NS attributes, don't complain if the parameter
or return types are dependent. Fixes PR9049.

llvm-svn: 141518
2011-10-09 22:26:49 +00:00
Richard Smith 256336d9ab Mark the ExtWarn for in-class initialization of static const float members as a GNU extension. Don't extend the scope of this extension to all literal types in C++0x mode.
llvm-svn: 140820
2011-09-29 23:18:34 +00:00
Richard Smith 2316cd8b79 constexpr: semantic checking for constexpr variables.
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).

llvm-svn: 140801
2011-09-29 19:11:37 +00:00
Douglas Gregor 882a61a640 Diagnose attempts to use 'using typename' with a non-identifier name,
from Stepan Dyatkovskiy. Fixes PR10925.

llvm-svn: 140528
2011-09-26 14:30:28 +00:00
Douglas Gregor 5223529b27 Don't finalize checking of base and member initializers for a
constructor template. Fixes PR10457.

llvm-svn: 140350
2011-09-22 23:04:35 +00:00
Douglas Gregor 7c26c04ba9 Diagnose attempts to write a templated data member, from Stepan
Dyatkovskiy! Fixes PR10896.

llvm-svn: 140250
2011-09-21 14:40:46 +00:00
Eli Friedman 8eac6c2187 PR10864: make sure we correctly delay type-checking for inline asm tied operands with dependent type. Patch by Likai Liu.
llvm-svn: 139716
2011-09-14 19:20:00 +00:00
Douglas Gregor 6b3bcf29f5 When type-checking a call to an overloaded, builtin atomic operation,
construct a new DeclRefExpr rather than re-using the existing
DeclRefExpr. Patch by Likai Liu, fixes PR8345.

llvm-svn: 139373
2011-09-09 16:51:10 +00:00
Francois Pichet bcf6471010 In Microsoft mode, if we are inside a template class member function and we can't resolve a function call then create a type-dependent CallExpr even if the function has no type dependent arguments. The goal is to postpone name lookup to instantiation time to be able to search into type dependent base classes.
With this patch in, clang will generate only 37 errors (down from 212) when parsing a typical MFC source file.

llvm-svn: 139210
2011-09-07 00:14:57 +00:00
Eli Friedman 755c0c996a Don't assert on taking the address of a non-type template parameter. Fixes PR10766.
llvm-svn: 138648
2011-08-26 20:28:17 +00:00