[Bug c++/109877] New: Support for clang-style attributes is needed to parse Darwin SDK headers properly

[Bug c++/109877] New: Support for clang-style attributes is needed to parse Darwin SDK headers properly

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

            Bug ID: 109877
           Summary: Support for clang-style attributes is needed to parse
                    Darwin SDK headers properly
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

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.

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

Iain Sandoe <iains at gcc dot gnu.org> 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 <iains at gcc dot gnu.org> ---
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.

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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....

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |*-darwin
            Version|unknown                     |14.0

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
can we fixinclude the headers?

[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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