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: Tue, 20 Jun 2023 15:08:44 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Alex

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

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

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

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

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


  reply	other threads:[~2023-06-20 14:08 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 [this message]
2023-07-06 14:01       ` Alex Coplan
2023-07-06 15:23         ` Iain Sandoe

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