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

[Iain Sandoe <iain@sandoe.co.uk>]

Hi Alex,

> On 6 Jul 2023, at 15:01, Alex Coplan <alex.coplan@arm.com> wrote:
> 
> On 20/06/2023 15:08, Iain Sandoe wrote:

>> 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?

Yes, I’ve tried it (together with some of my pending patches) on a few systems and
it LGTM - agreed we can probably implement a target hook if/when that becomes
necessary to register target-specific cases.

The Objective-C parts are OK (when the rest is approved)

thanks again for working on this.
Iain

> 
> 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