[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements
Valeriy Savchenko via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Dec 23 07:09:03 PST 2020
vsavchenko added a comment.
In D93630#2468853 <https://reviews.llvm.org/D93630#2468853>, @aaron.ballman wrote:
> Yeah, I kind of figured that might be the cause. I'm not 100% convinced (one way or the other) if the suppress attribute should get a GNU spelling. The `[[]]` spellings are available in all language modes (we have `-fdouble-square-bracket-attributes` to enable this) and don't run afoul of the "guess what this attribute appertains to" problem that GNU-style attributes do.
I don't think that we can force our users into adding this flag. Also, Obj-C codebases already use a good amount of GNU-style attributes, so it is pretty natural there.
================
Comment at: clang/lib/Parse/ParseStmt.cpp:213
ParsedStmtContext()) &&
- (GNUAttributeLoc.isValid() || isDeclarationStatement())) {
+ ((GNUAttributeLoc.isValid() && !Attrs.back().isStmtAttr()) ||
+ isDeclarationStatement())) {
----------------
aaron.ballman wrote:
> I think you need to ensure there's at least one attribute before checking `!Attrs.back().isStmtAttr()` as this may cause problems if the user does something odd like `__attribute__(()) int x;` (I don't know if this will result in a valid `GNUAttributeLoc` with no attributes or not.)
>
> I'm not certain that logic is perfect either. It would be pretty mysterious to handle these cases differently:
> ```
> __attribute__((stmt_attr, decl_attr)) int a, b, c;
> __attribute__((decl_attr, stmt_attr)) int x, y, z;
> ```
Yep, my bad. I changed it so that ALL the attributes in the front should be statement attributes.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D93630/new/
https://reviews.llvm.org/D93630
More information about the cfe-commits
mailing list