*ping*

Per Richard's suggestion, instead of including the cached tokens into the decltype annotation, i revert the cache to match the end of where we think the (broken) decltype annotated token should end.

In D91651#2416423, @thakis wrote:

Do you have any numbers on false positives / true positives uncovered by this tweak?

*ping*

committed here: https://github.com/llvm/llvm-project/commit/9930d4dff31a130890f21a64f43d530a83ae3d0a

*ping*

Based on Richards Feedback, this update includes the following changes:

• avoids calling the fragile getZextValue() for comparing against bit-field width, and uses APSInt's comparison operator overload
• suppresses/avoids the warning for unnamed bit-fields
• simplifies the test case and avoids preprocessor cleverness (and thus an extra pass).

Committed here: https://github.com/llvm/llvm-project/commit/e6aa06545b123292be283af7c414daead23cf9ab .

Thanks Thorsten - if no one else does it - i'll try and commit this for you
later today :)

This diff makes the following changes to the previous patch (based on feedback from Richard, Aaron and Wyatt):

• avoid introducing an initialism (FDK) into the clang namespace and unabbreviated each corresponding use to 'FunctionDefinitionKind'. Let me know if it seems too verbose - if so, perhaps a compromise along Wyatt's suggestion might behoove our source.
• changed the destination type from 'unsigned' to 'unsigned char' in our static_casts.
  • is that preferred, or should i have left it as 'unsigned'?
  • is there any real benefit here to specifying an underlying type of 'unsigned char' for our enum (that is never used as an opaque enum).

This revision includes the following changes to the initial patch:

• revert the bit-field to unsigned from enum (so as to avoid that nettlesome gcc warning)
• specified a fixed underlying type of 'unsigned char' for the enum FunctionDefinitionKind
• added static_casts when initiatilizing or assigning to the bit-field (which as Aaron astutely noticed was confined to the ctor and setter)

Committed: https://github.com/llvm/llvm-project/commit/e4d27932a59fb61aaba3ff7a3ccd1b5bc9215fb9

In D91035#2383167, @wchilders wrote:

Generally agree with this direction; Are there plans for migrating https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/Specifiers.h in a similar fashion, for consistency?

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?