User Details
- User Since
- Nov 12 2012, 12:47 PM (577 w, 3 d)
Sep 16 2023
Sorry about the delay - this patch has landed - https://github.com/llvm/llvm-project/commit/5bdd5d064d5171b2d5ff6268528cfffd2f86b8ea
Thanks!
Sep 6 2023
May 7 2023
Jan 13 2023
I'll try and look into it this weekend and have some sort of updated news
for you by monday?
Faisal Vali
Apr 11 2022
Apr 7 2022
Dec 14 2020
*ping*
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
Nov 23 2020
*ping*
Nov 21 2020
committed here: https://github.com/llvm/llvm-project/commit/9930d4dff31a130890f21a64f43d530a83ae3d0a
Nov 20 2020
*ping*
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
Nov 8 2020
Nov 7 2020
May 16 2020
Apr 25 2018
Apr 24 2018
Apr 4 2018
LGTM - can you commit?
Thank you!
Thanks Erik!
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
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?
thank 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! :)