[PATCH] D105759: Implement P2361 Unevaluated string literals
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 27 13:32:49 PDT 2023
aaron.ballman added inline comments.
================
Comment at: clang/include/clang/Basic/Attr.td:3048
}];
+ let ParseArgumentsAsUnevaluated = 1;
}
----------------
cor3ntin wrote:
> aaron.ballman wrote:
> > I don't think we should reuse this flag this way. This flag is for the traditional sense of "unevaluated", but unevaluated string literals are a different kind of beast. I think that should be tracked on the argument level. We can either adjust:
> > ```
> > class StringArgument<string name, bit opt = 0> : Argument<name, opt>;
> > ```
> > so that it takes another bit for whether the string is unevaluated or not, or we could add a new subclass for `UnevaluatedStringArgument`. Then ClangAttrEmitter.cpp would look at this information when emitting the switch cases.
> This is the previous approach i forgot to fixup everywhere.
> My current approach is to always consider StringArgument unevaluated.
> I don't think it make sense to have both StringArgument and UnevaluatedStringArgument.
> Currently in all the places we accept StringArgument, we check it's a possibly parenthesized StringLiteral
>
> If you want an evaluated string literal, an expression that produce a const char* or something should work
> My current approach is to always consider StringArgument unevaluated.
> I don't think it make sense to have both StringArgument and UnevaluatedStringArgument.
I think that's potentially a pretty significant change in behavior until we actually evaluate (ahahaha, puns!) all the vendor attributes using a `StringArgument`. Also, I thought you mentioned you planned to leave variadic string arguments as evaluated strings, so there would be a pretty surprising inconsistency to the behavior there. I would feel more comfortable not changing the behavior of attributes we've not validated are still correct when using unevaluated strings.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105759/new/
https://reviews.llvm.org/D105759
More information about the cfe-commits
mailing list