[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

John Marshall <John.W.Marshall at glasgow dot ac.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |John.W.Marshall at glasgow dot ac.
                   |                            |uk

--- Comment #4 from John Marshall <John.W.Marshall at glasgow dot ac.uk> ---
(In reply to comment #3)
> > --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
> > * for the other things, if it's a beta, then perhaps there's some chance it
> > will be fixed before issue.
> 
> Right: I believe I got at least one such bug fixed during 10.14 Beta.

FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120),
though I'm just some rando on the internet so they probably haven't even read
it yet. With a few dozen more duplicate reports they might look into it... :-) 
(See https://twitter.com/jomarnz/status/1136275996515155969 and thread.)

> > * we 
> >   - unconditionally define __has_xxxxxx(x) 0 in Darwin's builtin defines
> 
> That's most likely the easiest way out.

I don't think that'll help the AvailabityInternal.h problem as presumably these
things are already decaying to 0, leading to a path through
AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14 et
al. So predefining them to 0 will lead to the same path, no?

>>   - implement __has_xxxxx() .. which would be nicer, but not sure who has time
>> to do it .. 

I've been feeling some temptation to implement __attribute__(availability(...))
as a no-op that just ignores its arguments. It would be preferable for Apple to
put the fallback definitions back into their header, but failing that
capitulating to __availability__ seems least-worst.

(That'd probably be big enough that I'd have to finally get myself
copyright-assigned first.)