clang has GNU-style attribute support, but with essentially per-attribute parsing of the attribute argument list. This extends to, for example: __attribute__((availability(macOS, introduced=12.3.4))) and: __attribute__((availability(macOS, message="partial string" "more string"))) These are examples that GCC rejects; The issue actually need addressing during lexing since the first is an invalid token for a number (it's intended to represent a version) and we reject it before the parser has a chance to treat it specially. Ergo, we need a way to escape clang-specific attributes so that we can parse them.
I have a working draft for c-family (I do not know if D and M2 are interested in attributes)
This style of attributes is bad. Because the GNU style attribute is just token(expression,expression,expression) it seems odd that they added these kind of attributes without thinking maybe it would be rejected somewhere else.
(In reply to Andrew Pinski from comment #2) > This style of attributes is bad. Because the GNU style attribute is just > token(expression,expression,expression) it seems odd that they added these > kind of attributes without thinking maybe it would be rejected somewhere > else. Actually, the folks from clang I've spoken to agree it is bad; however, it's also in the wild and so unfixable - at least for the key attributes such as availability. I hope that future additions will not take advantage of the extra flexibility. From the PoV of the platform I'm kinda stuck [and it seems those attributes are also used by, at least, android, z/OS and hlsl from the list in the clang sources].
(In reply to Andrew Pinski from comment #2) > This style of attributes is bad. Because the GNU style attribute is just > token(expression,expression,expression) it seems odd that they added these > kind of attributes without thinking maybe it would be rejected somewhere > else. To be precise, some attributes have the first argument an identifier rather than expression (e.g. mode/format/cleanup/access attribute). So, the macOS as first argument is acceptable, but not the second one.
(In reply to Jakub Jelinek from comment #4) > (In reply to Andrew Pinski from comment #2) > > This style of attributes is bad. Because the GNU style attribute is just > > token(expression,expression,expression) it seems odd that they added these > > kind of attributes without thinking maybe it would be rejected somewhere > > else. > > To be precise, some attributes have the first argument an identifier rather > than expression (e.g. mode/format/cleanup/access attribute). > So, the macOS as first argument is acceptable, but not the second one. As far as I can tell (and what my current implementation does) is to say that everything in the inner parentheses cam be lexed/parsed in a manner specific to the attribute ID. so in: availability(zzzz) the zzzz is parsed specifically to "availability" and presumably: another_attr(yyyy) could have a different set of rules. As noted, we [at least, all I have spoken to] agree that this is bad (in respect of deviating from GNU style without any other mechanism to differentiate). However, once stuff is in the wild....
That is generally the case for the standard C/C++ attributes (arguments just need to be a balanced token sequence), but not for GNU attributes. Although, all standard C/C++ attributes we support right now other than OpenMP ones follow the GNU attribute rules as well.
can we fixinclude the headers?
(In reply to Richard Biener from comment #7) > can we fixinclude the headers? 1. not yet (PR105719) - although let us hope we can find a way to do that for more limited cases (I've implemented the consumer code, but the generation and install side is more work). 2. In any event, (especially for 'availability') that would be a huge job (essentially re-writing a significant bunch of framework and /usr/include cases), and keeping up with frequent Xcode / SDK updates would be quite a maintenance burden***. 3. It does not help our downstream to use other projects which make use of these features (in non-SDK sources). ---- *** other options considered: for "closed" SDKs for system versions out of vendor support, I suppose we could just have a script that sed'ed the headers into a replacement, but that is still some machinery to implement. It would be nice to have an open SDK - but that is a huge project in its own right, and likewise would need someone with time to maintain the bleeding edge version