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

llvm-svn: 152191

Make sure we consistently canonicalize types when canonicalizing TemplateTemplateParmDecls.  PR12179.

llvm-svn: 152189

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

A couple minor bug-fixes for template instantiation for expressions which are sometimes potentially evaluated.

llvm-svn: 151707

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

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

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

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

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

llvm-svn: 150240

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

llvm-svn: 149868

llvm-svn: 149177

get a function parameter pack (but don't due to weird substitutions),
complain. Fixes the last bit of PR11848.

llvm-svn: 148960

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

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

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

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

'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.

llvm-svn: 147357

good parser error recovery and for not crashing.

We still have a accepts-invalid-code bug.

llvm-svn: 147216

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

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

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

Add notes for suppressing and (if it's a zero-arg function returning bool) fixing the function-to-bool conversion warning.

llvm-svn: 146280

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

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

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

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

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

In Microsoft mode, make "Unqualified lookup into dependent bases of class templates" works  inside static functions.

llvm-svn: 144729

at the bases of an undefined class. Fixes <rdar://problem/10438657>.

llvm-svn: 144582

Move "Unqualified lookup into dependent bases of class templates" Microsoft specific behavior from -fms-extensions to -fms-compatibility.

llvm-svn: 144341

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

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

entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.

llvm-svn: 143967

llvm-svn: 143725

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

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

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