Apr 11 2022
Apr 7 2022
Dec 14 2020
Dec 6 2020
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.
Nov 25 2020
Do you have any numbers on false positives / true positives uncovered by this tweak?
Nov 23 2020
Nov 21 2020
Nov 20 2020
Nov 19 2020
Nov 17 2020
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).
Nov 15 2020
Nov 14 2020
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).
Nov 12 2020
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)
Nov 11 2020
Nov 10 2020
Nov 9 2020
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?
Nov 8 2020
Nov 7 2020
May 16 2020
Apr 25 2018
Apr 24 2018
Apr 4 2018
LGTM - can you commit?
Apr 3 2018
Thanks for working on this fairly embarrassing bug (let's fix this before the week is over :)
Mar 14 2018
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 ...
Jan 1 2018
Dec 31 2017
Dec 30 2017
Dec 29 2017
Dec 28 2017
Dec 27 2017
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.
Dec 25 2017
Dec 24 2017
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?
Dec 23 2017
Dec 21 2017
Added via https://reviews.llvm.org/rC321339
Dec 20 2017
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!
Dec 19 2017
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)...
Dec 17 2017
Otherwise, I think this looks good enough to commit.
Thanks for working on this! :)
Dec 16 2017
Dec 1 2017
Nov 11 2017
Just added an additional bit-field to FunctionDecl in https://reviews.llvm.org/rL317984
Oct 25 2017
Incorporated Aaron's feedback (although not sure if I caugh tall the white space issues).
Oct 22 2017
Isn't it already an UB if someone set WillHaveBody and but later IsCopyDeductionCandidate being read, vice versa?