[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #8 from Iain Sandoe --- (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
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Richard Biener changed: What|Removed |Added Target||*-darwin Version|unknown |14.0 --- Comment #7 from Richard Biener --- can we fixinclude the headers?
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #6 from Jakub Jelinek --- 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.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #5 from Iain Sandoe --- (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() the is parsed specifically to "availability" and presumably: another_attr() 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
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (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.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #3 from Iain Sandoe --- (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].
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #2 from Andrew Pinski --- 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.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Iain Sandoe changed: What|Removed |Added Blocks||90709 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2023-05-16 --- Comment #1 from Iain Sandoe --- I have a working draft for c-family (I do not know if D and M2 are interested in attributes) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709 [Bug 90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.
