From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by sourceware.org (Postfix) with ESMTPS id CABC33858D33 for ; Thu, 6 Jul 2023 15:23:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CABC33858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sandoe.co.uk Received: (qmail 8710 invoked from network); 6 Jul 2023 15:23:29 -0000 X-APM-Out-ID: 16886570090870 X-APM-Authkey: 257869/1(257869/1) 15 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 6 Jul 2023 15:23:29 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: [PATCH][RFC] c-family: Implement __has_feature and __has_extension [PR60512] From: Iain Sandoe In-Reply-To: Date: Thu, 6 Jul 2023 16:23:28 +0100 Cc: GCC Patches , Joseph Myers , Jason Merrill , Nathan Sidwell Content-Transfer-Encoding: quoted-printable Message-Id: <9009BA7E-1F23-407D-B044-04EB97BC52D1@sandoe.co.uk> References: <77197F1C-5183-4F12-8701-83ACFF5FC96F@sandoe.co.uk> <9CCD1364-B659-4788-834F-5ECF52944660@sandoe.co.uk> To: Alex Coplan X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alex, > On 6 Jul 2023, at 15:01, Alex Coplan wrote: >=20 > On 20/06/2023 15:08, Iain Sandoe wrote: >> again, thanks for working on this and for fixing the SDK blocker. >>=20 >>> On 20 Jun 2023, at 13:30, Alex Coplan wrote: >>>=20 >>=20 >>> 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). >>=20 >> Yes, I=E2=80=99ll 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). >>=20 >>>> (one reason to allow target opt-in/out of specific features) >>>>=20 >>>>> with the following omissions: >>>>=20 >>>>> - Objective-C-specific features. >>>>=20 >>>> 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). >>>>=20 >>>> this is why I think we need more flexible predicates on declaring = features >>>> and extensions. >>>=20 >>> 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)? >>>=20 >>> 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. >>>=20 >>> What do you think, does that sound OK to you? >>=20 >> 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. >=20 > FWIW I've implemented some Objective-C features (those from your WIP = patch) > in a v2 patch here: >=20 > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623057.html >=20 > 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. >=20 > Any thoughts on the new version? Yes, I=E2=80=99ve 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 >=20 > Thanks, > Alex >=20 >>=20 >>>> What about things like this: >>>>=20 >>>> attribute_availability_tvos,=20 >>>> attribute_availability_watchos,=20 >>>> attribute_availability_driverkit,=20 >>>=20 >>> FWIW, clang looks to define these unconditionally, so restricting = these >>> to a given target would be deviating from its precedent. >>=20 >> Hmm.. i did not check that although (for the sake of keeping = target-specific >> code localised) my current availabilty attribute implementation is = Darwin- >> specific. >>=20 >> 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. >>=20 >>> 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. >>=20 >> Indeed, that could work if the result is needed later than = pre-processing. >>=20 >> In my patch, IIRC, I added another entry to the libcpp callbacks to = handle >> target-specific __has_xxxx queries. >>=20 >> cheers >> Iain