Re: [PATCH][RFC] c-family: Implement __has_feature and __has_extension [PR60512]

[Alex Coplan <alex.coplan@arm.com>]

Hi Iain,

On 20/06/2023 15:08, Iain Sandoe wrote:
> Hi Alex
> 
> again, thanks for working on this and for fixing the SDK blocker.
> 
> > On 20 Jun 2023, at 13:30, Alex Coplan <alex.coplan@arm.com> wrote:
> > 
> 
> > The patch can now survive bootstrap on Darwin (it looks like we'll need
> > to adjust some Objective-C++ tests in light of the new pedwarn, but that
> > looks to be straightforward).
> 
> Yes, I’ll deal with that soon (I was trying to decide whether to fix the the
> header we have copied from GNUStep, or whether to mark it as a system
> header).
> 
> >> (one reason to allow target opt-in/out of specific features)
> >> 
> >>> with the following omissions:
> >> 
> >>> - Objective-C-specific features.
> >> 
> >> I can clearly append the objective-c(++) cases to the end of the respective
> >> lists, but then we need to make them conditional on language, version and
> >> dialect (some will not be appropriate to GNU runtime).
> >> 
> >> this is why I think we need more flexible predicates on declaring features
> >> and extensions.
> > 
> > Would it help mitigate these concerns if I implemented some Objective-C
> > features as part of this patch (say, those implemented by your WIP
> > patch)?
> > 
> > My feeling is that the vast majority of extensions / features have
> > similar logic, so we should exploit that redundancy to keep things terse
> > in the encoding for the general case. Where we need more flexible
> > predicates (e.g. for objc_nonfragile_abi in your WIP patch), those can
> > be handled on a case-by-case basis by adding a new enumerator and logic
> > to handle that specially.
> > 
> > What do you think, does that sound OK to you?
> 
> Sketching out what you have in mind using one or two examples would be
> helpful.  Again, the fact that some of the answers are target-dependent, is
> what makes me think of needing a little more generality.

FWIW I've implemented some Objective-C features (those from your WIP patch)
in a v2 patch here:

https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623057.html

I also tweaked the design to be closer to your patch in that we now have a hash
table which allows for registering features dynamically. Hopefully it's clear
that it should be easier to handle target-specific features in that version.

Any thoughts on the new version?

Thanks,
Alex

> 
> >> What about things like this:
> >> 
> >> attribute_availability_tvos, 
> >> attribute_availability_watchos, 
> >> attribute_availability_driverkit, 
> > 
> > FWIW, clang looks to define these unconditionally, so restricting these
> > to a given target would be deviating from its precedent.
> 
> Hmm.. i did not check that although (for the sake of keeping target-specific
> code localised) my current availabilty attribute implementation is Darwin-
> specific.
> 
> Having said that, interoperability with clang is also a very useful goal - for
> Darwin, the SDK headers have only been (fully) tested with clang up to
> now and I am sure we will find more gotchas as we expand what we can
> parse.
> 
> > However, I don't think it would be hard to extend the implementation in
> > this patch to support target-specific features if required. I think
> > perhaps a langhook that targets can call to add their own features would
> > be a reasonable approach.
> 
> Indeed, that could work if the result is needed later than pre-processing.
> 
> In my patch, IIRC, I added another entry to the libcpp callbacks to handle
> target-specific __has_xxxx queries.
> 
> cheers
> Iain
> 
>