public inbox for
 help / color / mirror / Atom feed
From: Iain Sandoe <>
To: Alex Coplan <>
Cc: GCC Patches <>,
	Joseph Myers <>,
	Jason Merrill <>, Nathan Sidwell <>
Subject: Re: [PATCH][RFC] c-family: Implement __has_feature and __has_extension [PR60512]
Date: Thu, 6 Jul 2023 16:23:28 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Alex,

> On 6 Jul 2023, at 15:01, Alex Coplan <> 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 <> 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:
> 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.

> 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

      reply	other threads:[~2023-07-06 15:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 12:07 Alex Coplan
2023-05-11 20:25 ` Jason Merrill
2023-05-11 21:26   ` Jonathan Wakely
2023-07-06 13:58   ` Alex Coplan
2023-05-14 16:05 ` Iain Sandoe
2023-06-20 12:30   ` Alex Coplan
2023-06-20 14:08     ` Iain Sandoe
2023-07-06 14:01       ` Alex Coplan
2023-07-06 15:23         ` Iain Sandoe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).