LGTM - can you commit?
Thank you!

Thanks Erik!

Thanks for working on this fairly embarrassing bug (let's fix this before the week is over :)

I discussed this briefly w Hubert - and i'm planning on modifying this patch slightly so that it flows through ParseDeclSpecifier and handles attributes and other invalid decl-specifiers such as static etc. more gracefully on a concept decl. I have this partially implemented - my hope is to get this done v soonish so feel free to ping me if you don't hear anything about this in a week or so ...

In D41179#964522, @miyuki wrote:

In D41179#957992, @sepavloff wrote:

Classes do not have language linkage according to 10.5p1, just as templates, so this code is valid.

It looks like defining templates inside extern "C" blocks is OK.

Currently both Clang and GCC diagnose class templates declared inside an 'extern "C"' block. I'm not sure how to proceed about this.

I think this looks good enough to commit - do you have commit privileges - or do you need one of us to commit it for you?
thank you!

Added via https://reviews.llvm.org/rC321339

Miyuki - please take a look at the patch and let me know if you agree with the changes - or have any concerns...

Sounds good - if I don't get this done over the next seven days - would you mind just pinging me!

Hmm - I think i might make some tweaks to this patch (to be largely symmetric with the similar handling of invalid decl-specifiers on function parameters in Sema::Actions.ActOnParamDeclarator)...

Otherwise, I think this looks good enough to commit.

Thanks for working on this! :)

Just added an additional bit-field to FunctionDecl in https://reviews.llvm.org/rL317984

Incorporated Aaron's feedback (although not sure if I caugh tall the white space issues).

In D39166#903131, @lichray wrote:

Isn't it already an UB if someone set WillHaveBody and but later IsCopyDeductionCandidate being read, vice versa?

committed as r315840.
https://reviews.llvm.org/rL315840

Sorry about the break - But thank you for the fix :)

OK. It appears to be something along these lines:

Could you please update the documentation (and let me know) here (http://clang.llvm.org/hacking.html) on how to use the updated configuration to run the tests.

In D36527#854883, @faisalv wrote:

In D36527#854600, @rsmith wrote:

This patch appears to be missing some necessary changes in the following places:

• lib/Serialization -- round-trip the new information through PCH / modules

In D36915#854317, @ahatanak wrote:

In D36915#849622, @faisalv wrote:

I don't think this approach is entirely correct for at least the following reasons:

1. in the lambda case the machinery that diagnoses capture failures should be the machinery erroring on the lambda (when the parameter is odr-used)

Does this mean that it is OK to have a parameter or local variable appear in a potentially-evaluated expression as long as it is not odr-used? I think this is slightly different from the standard, which says a parameter or local variable cannot appear as a potentially-evaluated expression in a default argument.

For example:

void foo2(int);

void func() {
  const int a = 1;
  void foo1(S s = [](){ foo2(a); }); // "a" is not in an unevaluated context and is not odr-used.
}

I think I need clarification as it will affect how or where we detect this error.

OK - I'll commit this on sunday if no one blocks it by then. (I'll add the fixme's).

I don't think this approach is entirely correct for at least the following reasons:

1. in the lambda case the machinery that diagnoses capture failures should be the machinery erroring on the lambda (when the parameter is odr-used)
2. in the unevaluated case, once you disable the error, the instantiation machinery will fail to find the corresponding instantiated parmvardecl.