std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.

In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.

This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252688 91177308-0d34-0410-b5e6-96231b3b80d8

(or of a lambda init-capture, which is sort-of such a variable). The semantics
of such constructs will change when we implement N3922, so we intend to warn on
this in Clang 3.6 then change the semantics in Clang 3.7.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228792 91177308-0d34-0410-b5e6-96231b3b80d8

It is not correct to let it consume the cxx_defaultarg_end token.  I'm
starting to wonder if it makes more sense to stop SkipUntil from
consuming such tokens.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225615 91177308-0d34-0410-b5e6-96231b3b80d8

Recovery from malformed lambda introducers would find us consuming the
synthetic default argument token, which is bad.  Instead, stop right
before that token.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225613 91177308-0d34-0410-b5e6-96231b3b80d8

Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.

This fixes PR22122.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225505 91177308-0d34-0410-b5e6-96231b3b80d8

properly.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206128 91177308-0d34-0410-b5e6-96231b3b80d8

For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205398 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203628 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203602 91177308-0d34-0410-b5e6-96231b3b80d8

Changing this test case to use an unknown attribute, since there are not currently any type attributes which would apply to a lambda, except in MSVC compatibility mode.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203566 91177308-0d34-0410-b5e6-96231b3b80d8

Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203565 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191609 91177308-0d34-0410-b5e6-96231b3b80d8

and capturing a variable declaration, and complete the implementation of them.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191605 91177308-0d34-0410-b5e6-96231b3b80d8

a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.

You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181985 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181553 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166619 91177308-0d34-0410-b5e6-96231b3b80d8

be filled in; they won't if the lambda's declarator has an invalid type. Instead
take the parameters from the declarator directly.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162904 91177308-0d34-0410-b5e6-96231b3b80d8

In 'delete []', the '[]' never starts a lambda. Update a FIXME with a standard reference and add a test.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161604 91177308-0d34-0410-b5e6-96231b3b80d8

being defined here: [] () -> struct S {} does not define struct S.

In passing, implement DR1318 (syntactic disambiguation of 'final').


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152551 91177308-0d34-0410-b5e6-96231b3b80d8

designators in the parser. In the worst case, this disambiguation
requires tentative parsing just past the closing ']', but for most
cases we'll be able to tell by looking ahead just one token (without
going into the heavyweight tentative parsing machinery).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150790 91177308-0d34-0410-b5e6-96231b3b80d8

trailing return type but not a '()'. Recover by inserting the
parentheses. Thanks to Xeo on IRC for the example.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150727 91177308-0d34-0410-b5e6-96231b3b80d8

and rapidly becoming untrue.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150165 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150126 91177308-0d34-0410-b5e6-96231b3b80d8

Stub out the Sema interface for lambda expressions, and change the parser to use it.  Unconditionally error on lambda expressions because they don't work in any meaningful way yet.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147515 91177308-0d34-0410-b5e6-96231b3b80d8

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)



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146619 91177308-0d34-0410-b5e6-96231b3b80d8

-std=c++0x. Patch by Ahmed Charles!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141900 91177308-0d34-0410-b5e6-96231b3b80d8

David Blaikie!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136876 91177308-0d34-0410-b5e6-96231b3b80d8