Commit Graph

1037 Commits

Author SHA1 Message Date
Andy Gibbs c6e68daac0 Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
2012-10-19 12:44:48 +00:00
Nick Lewycky 2e3b716959 Revert r166268, this fix for a crash-on-invalid introduced a rejects-valid.
Richard has an unreduced testcase to work with.

llvm-svn: 166272
2012-10-19 08:08:02 +00:00
Richard Smith b2d6df5c95 PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.

llvm-svn: 166268
2012-10-19 06:32:17 +00:00
Eli Friedman c681e5f608 Fix a regression from r164656.
llvm-svn: 164804
2012-09-27 22:13:33 +00:00
Richard Smith 60f2e1efb8 Don't produce diagnostics for missing ctor-initializers during template
instantiations if we encountered errors parsing some of the initializers.

llvm-svn: 164578
2012-09-25 00:23:05 +00:00
Richard Smith 6d12af7410 Fix bug which sometimes resulted in further diagnostics being produced after a
fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.

llvm-svn: 164437
2012-09-22 00:53:56 +00:00
Douglas Gregor c5c01a60c2 Don't perform template argument deduction against invalid templates;
it's likely to lead to a crash later on. Fixes PR12933 /
<rdar://problem/11525335>.

llvm-svn: 163838
2012-09-13 21:01:57 +00:00
Richard Smith 09b031fbc0 Don't try to check override control for invalid member functions. Fixes a crash in a corner case. Patch by Olivier Goffart!
llvm-svn: 163337
2012-09-06 18:32:18 +00:00
Nico Weber 723b4f02a7 Reland r160052: Default to -std=c++11 on Windows.
Also update the tests that rely on c++98 to explicitly mention that.

llvm-svn: 162890
2012-08-30 02:08:31 +00:00
Richard Smith 4f605aff7f PR41111, PR5925, PR13210: Teach tentative parsing to annotate identifiers and
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).

This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.

llvm-svn: 162159
2012-08-18 00:55:03 +00:00
David Blaikie 1c7c8f7637 Implement warning for integral null pointer constants other than the literal 0.
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...

There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.

Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.

Review by Sean Silva and Richard Smith.

llvm-svn: 161501
2012-08-08 17:33:31 +00:00
Richard Smith 943c440455 Improvements to vexing-parse warnings. Make the no-parameters case more
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.

Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.

llvm-svn: 160998
2012-07-30 21:30:52 +00:00
Richard Smith d3b5c90865 Final piece of core issue 1330: delay computing the exception specification of
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).

EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.

This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.

The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.

Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).

llvm-svn: 160847
2012-07-27 04:22:15 +00:00
Richard Smith 3beb930cfd More for PR11848: a pack expansion type isn't necessarily type-dependent (its
pattern might be an alias template which doesn't use its arguments). It's always
instantiation-dependent, though.

llvm-svn: 160246
2012-07-16 01:59:26 +00:00
Richard Smith 8093465a0b PR13365: Fix code which was trying to treat an array of DeducedTemplateArgument
as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.

llvm-svn: 160245
2012-07-16 01:09:10 +00:00
Richard Smith 68eea507fa Related to PR11848 and core-21989: switch ContainsUnexpandedParameterPack from
being a property of a canonical type to being a property of the fully-sugared
type. This should only make a difference in the case where an alias template
ignores one of its parameters, and that parameter is an unexpanded parameter
pack.

llvm-svn: 160244
2012-07-16 00:20:35 +00:00
Richard Smith 7dfc0240ea PR13368: Halve the instantiation depth of this test again. Apparently, FreeBSD
has a much lower default stack limit than the systems I have access to.

llvm-svn: 160240
2012-07-15 23:29:50 +00:00
Richard Smith 57e7ff9c0c Provide a special-case diagnostic when two class member functions instantiate
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.

llvm-svn: 160161
2012-07-13 04:12:04 +00:00
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
Matt Beaumont-Gay 045bde420b Fix a crash-on-invalid.
Much to everyone's surprise, the default constructor for TypeResult produces
an instance with Invalid == false. This seems like a decision we may want to
revisit.

llvm-svn: 138601
2011-08-25 23:22:24 +00:00
Chandler Carruth 463394752b Whitelist operator== and operator!= as valid for unused value warnings,
even when overloaded and user-defined. These operators are both more
valuable to warn on (due to likely typos) and extremely unlikely to be
reasonable for use to trigger side-effects.

llvm-svn: 137823
2011-08-17 09:49:44 +00:00
Chandler Carruth e2669397f1 Treating the unused equality comparisons as something other than part of
-Wunused was a mistake. It resulted in duplicate warnings and lots of
other hacks. Instead, this should be a special sub-category to
-Wunused-value, much like -Wunused-result is.

Moved to -Wunused-comparison, moved the implementation to piggy back on
the -Wunused-value implementation instead of rolling its own, different
mechanism for catching all of the "interesting" statements.

I like the unused-value mechanism for this better, but its currently
missing several top-level statements. For now, I've FIXME-ed out those
test cases. I'll enhance the generic infrastructure to catch these
statements in a subsequent patch.

This patch also removes the cast-to-void fixit hint. This hint isn't
available on any of the other -Wunused-value diagnostics, and if we want
it to be, we should add it generically rather than in one specific case.

llvm-svn: 137822
2011-08-17 09:34:37 +00:00
Francois Pichet 127bea8f48 fix typo in test.
llvm-svn: 137592
2011-08-14 22:30:29 +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
Douglas Gregor 3d63a9e501 Make sure to canonicalize the argument type of a non-type template
argument of enumeration type when checking template arguments. Fixes PR10579.

llvm-svn: 137101
2011-08-09 01:55:14 +00:00
Francois Pichet b23dc0950b In Microsoft mode, if we are within a templated function and we can't resolve Identifier during BuildCXXNestedNameSpecifier, then extend the SS with Identifier. This will have the effect of resolving Identifier during template instantiation. The goal is to be able to resolve a function call whose nested-name-specifier is located inside a dependent base class.
class C {
public:
    static void foo2() {  }
};

template <class T> class A {
public:
   typedef C D;
};

template <class T> class B : public A<T> {
public:
  void foo() { D::foo2(); }
};

Note that this won't work if the NestedNameSpecifier refers to a type.
This fixes 1 error when parsing the MSVC 2010 standard headers file with clang.

llvm-svn: 136203
2011-07-27 01:05:24 +00:00
Douglas Gregor 72912fb9a4 When we decide not to rebuild an instantiated C++ 'new' expression
that allocates an array of objects with a non-trivial destructor, be
sure to mark the destructor is "used". Fixes PR10480 /
<rdar://problem/9834317>.

llvm-svn: 136081
2011-07-26 15:11:03 +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 6730e4d904 Restore the C-style cast hack for enum template arguments,
which is required given the current setup for template
argument deduction substitution validation, and add a test
case to make sure we don't break it in the future.

llvm-svn: 135262
2011-07-15 07:47:58 +00:00
Richard Smith 7b8c3c91f4 PR10359: Template declarations which define classes are not permitted to also contain declarators. Previously we would accept code like this:
template<typename T> struct S { } f() { return 0; }

This case now produces a missing ';' diagnostic, since that seems like a much more likely error than an attempt to declare a function or variable in addition to the class template.

Treat this 

llvm-svn: 135195
2011-07-14 21:35:26 +00:00
Douglas Gregor 6336f29669 Teach CXXUnresolvedConstructExpr when it should be an
lvalue/xvalue/rvalue, rather than just (incorrectly) assuming it's an
lvalue. Fixes PR10285 / <rdar://problem/9743926>.

llvm-svn: 134700
2011-07-08 15:50:43 +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 750734c677 Don't try to type-check a copy construction of an exception
declaration with dependent type. Fixes PR10232 /
<rdar://problem/9700653>.

llvm-svn: 134515
2011-07-06 18:14:43 +00:00
Douglas Gregor b7c0083878 Look through parenthesized declarators when determining whether an
instantiated function template was written with a prototype or via
some kind of typedef. Fixes PR10273 / <rdar://problem/9723679>. 

llvm-svn: 134426
2011-07-05 18:30:26 +00:00
Richard Smith cd1c055528 Fix AST representations of alias-declarations which define tag types. Inside classes, the tag types need to have an associated access specifier, and inside function definitions, they need to be included in the declarations of the DeclStmt. These issues manifested as assertions during template instantiation, and also in a WIP constexpr patch.
llvm-svn: 134250
2011-07-01 19:46:12 +00:00
Richard Smith 95ce4f67a3 Fix PR10187: when diagnosing a two-phase-lookup-related failure, don't assert that any names we find are valid candidates for the call.
llvm-svn: 133898
2011-06-26 22:19:54 +00:00
Douglas Gregor 1501f16cfe When instantiating a function template declaration that was expressed
via a typedef of a function, make sure to synthesize parameter
declarations. Fixes PR9654 / <rdar://problem/9257497>.

llvm-svn: 133628
2011-06-22 18:16:25 +00:00
Douglas Gregor 39c0272f65 Eliminate a 'default' case in template argument deduction, where we
were just punting on template argument deduction for a number of type
nodes. Most of them, obviously, didn't matter.

As a consequence of this, make extended vector types (via the
ext_vector_type attribute) actually work properly for several
important cases:
  - If the attribute appears in a type-id (i.e, not attached to a
  typedef), actually build a proper vector type
  - Build ExtVectorType whenever the size is constant; previously, we
  were building DependentSizedExtVectorType when the size was constant
  but the type was dependent, which makes no sense at all.
  - Teach template argument deduction to handle
  ExtVectorType/DependentSizedExtVectorType.

llvm-svn: 133060
2011-06-15 16:02:29 +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
Jay Foad 0b16695d93 Hyphenate "argument-dependent".
llvm-svn: 132989
2011-06-14 12:59:25 +00:00
David Majnemer c75d1a1098 Properly diagnose using abstract and incomplete types in va_arg
- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors

llvm-svn: 132979
2011-06-14 05:17:32 +00:00
David Majnemer 254a5c07e7 Give a diagnostic when using non-POD types in a va_arg
llvm-svn: 132905
2011-06-13 06:37:03 +00:00
Chandler Carruth d54186ac33 Fix a regression in the two-phase lookup diagnostics that switching the
namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.

llvm-svn: 132744
2011-06-08 10:13:17 +00:00
Richard Smith 998a591e32 Fix PR10053: Improve diagnostics and error recovery for code which some compilers incorrectly accept due to a lack of proper support for two-phase name lookup.
llvm-svn: 132672
2011-06-05 22:42:48 +00:00
Douglas Gregor 28de7a9a1e Improve the instantiation of static data members in
Sema::RequireCompleteExprType() a bit more, setting the point of
instantiation if needed, and skipping explicit specializations entirely.

llvm-svn: 132547
2011-06-03 14:28:43 +00:00
Douglas Gregor 57d4f972b7 When performing template argument deduction given a function argument
of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.

llvm-svn: 132530
2011-06-03 03:35:07 +00:00
Chandler Carruth 7c430c0ec2 Enhance Clang to start instantiating static data member definitions
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:

  template <typename T> struct S {
    static const int arr[];
    static const int x;
    static int f();
  };

  template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
  template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
  template <typename T> int S<T>::f() { return x; }

  int x = S<int>::f();

We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.

This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?

llvm-svn: 132172
2011-05-27 01:33:31 +00:00
Douglas Gregor 291e8ee206 It's considered poor form to create references to the overloaded
function type. Educate template argument deduction thusly, fixing
PR9974 / <rdar://problem/9479155>.

llvm-svn: 131811
2011-05-21 22:16:50 +00:00
Richard Smith 0c4a34b1a0 PR9908: Fix the broken fix for PR9902 to get the template argument lists in the right order.
Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers.

llvm-svn: 131342
2011-05-14 15:04:18 +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
Richard Trieu de756fbbd7 Patch for PR 7409 - only error on definition of invalid typedefs. Suppress errors for additional uses of this invalid typedef.
llvm-svn: 131043
2011-05-07 01:36:37 +00:00