[PATCH] D133853: [AST] Add msvc-specific C++11 attributes
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 19 05:23:54 PDT 2022
aaron.ballman added a comment.
In D133853#3797598 <https://reviews.llvm.org/D133853#3797598>, @RIscRIpt wrote:
> In D133853#3795579 <https://reviews.llvm.org/D133853#3795579>, @aaron.ballman wrote:
>
>> FWIW, one Microsoft-specific attribute I know people have been asking about is `[[msvc::no_unique_address]]`
>
> Thanks for letting me know.
>
> The current patch is my first attempt to contribute to LLVM; I am afraid it would take me some effort to implement semantics of `[[msvc::no_unique_address]]`, so I'd like to focus only on `[[msvc::constexpr]]` in current patch.
No worries, thanks for at least thinking about it!
> In D133853#3795598 <https://reviews.llvm.org/D133853#3795598>, @erichkeane wrote:
>
>> A functional `msvc::constexpr` would be acceptable, however, I'm having a difficult time figuring out the purpose of it, it seems like it is just a 'constexpr keyword' replacement?
It's a conforming extension in older language modes like C++98, where we couldn't steal the `constexpr` keyword because it's not reserved, which is one benefit to it. Does MSVC support this as far back as C++98?
>> I believe the 'unknown attribute' warning for them is superior to an ignored attribute.
>
> By the way, I'd like to take opportunity and ask what do you think of adding clang-specific compiler flag, which would add all unknown attributes to the AST in a string form (e.g. `[[attr1]] -> AST::UnknownAttr{"attr1"}`? Would you be interested in such patch?
We would be, but it's tricky. The idea we've had in mind for a while is to add an `UnknownAttr` type which wraps information the parser was able to scrape together. Things like the vendor namespace and attribute name are quite easy to keep around and would be a good initial offering. However, attribute arguments are going to be more difficult to handle because they can be arbitrary token soup rather than code which forms a valid AST node. e.g., `[[foo("oh no!")]]` isn't bad but `[[foo(we don't even know what this is)]]` and we can't even necessarily save off tokens for it because it could contain punctuation which isn't a valid token by itself, like `'` without a terminating single quote). So the initial offering could save the source range of the parens for the arguments (this way you can at least get back to the text in the source code if you need to), but I don't know that we have a good idea how to handle exposing the argument information.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133853/new/
https://reviews.llvm.org/D133853
More information about the cfe-commits
mailing list