aaron.ballman added a comment. In D93630#2468168 <https://reviews.llvm.org/D93630#2468168>, @vsavchenko wrote:
> @aaron.ballman I totally agree, but I also would like to understand. > `__attribute__` is a GNU extension, right? Correct. > Then why does it affect the grammar of C? I always thought that attributes > should be somewhat transparent for parsers, but it looks like in this > situation all compilers automatically assume that `__attribute__` begins a > declaration. GNU attributes are kind of awful in that they "slide" around to whatever construct seems to make the most sense based on the given attribute. My guess is that this assumption is baked into compilers because otherwise there would be parsing ambiguities. e.g., `__attribute__((attr)) int x = ..., y, z;` could either be a declaration attribute that applies to `x`, `y`, and `z` or maybe it's a statement attribute that's meant to suppress a diagnostic on the initialization of x (that sort of thing), and it would take too much lookahead to make a determination based on the attribute name. > It is unclear to me why `*x;`, `[[unknown]] *x;` (dereference of x) and > `__attribute__((unknown)) *x;` (declaration of `int *`) have different > meanings. C and C++ style attributes have a very well-defined meaning in terms of what they appertain to based on the syntactic location of the attribute rather than based on the name of the attribute. That's why `[[attr]] *x;` and `__attribute__((attr))) *x` behave differently. > Does it essentially mean that there is no way to implement statement > attributes in C/Obj-C? > Because even if we introduce some heuristics for understanding that what we > parsed is a declaration attribute -> what follows must be a declaration, > attributes that can be applied to both declaration and statements will cause > confusion. That was really the crux of the problem I kept running into as well. I wouldn't say there's "no way" to do it, but it's not as trivial as it feels like it should be. If we could tell that the attribute is a decl or stmt attribute, we could throw our hands up in that specific circumstance and say "this code is ambiguous", but then we're extending the syntactic locations of where GNU attributes can be written and what they mean (so we'd diverge from GCC). But then again, we've done that before (such as with allowing you to write a GNU-style attribute on a function definition, as in: https://godbolt.org/z/PGrfP3 (but this has caused users some pain, from what I understand). Perhaps coordinating with the GCC folks on this may not be a bad idea. However, taking a step back -- what attributes would need this functionality (and couldn't be written on something within the expression statement)? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93630/new/ https://reviews.llvm.org/D93630 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
