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 69EE83858D1E for ; Tue, 20 Jun 2023 14:08:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69EE83858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 40265 invoked from network); 20 Jun 2023 14:08:45 -0000 X-APM-Out-ID: 16872701254026 X-APM-Authkey: 257869/1(257869/1) 9 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp002.apm-internet.net with SMTP; 20 Jun 2023 14:08:45 -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: Tue, 20 Jun 2023 15:08:44 +0100 Cc: GCC Patches , Joseph Myers , Jason Merrill , Nathan Sidwell Content-Transfer-Encoding: quoted-printable Message-Id: <9CCD1364-B659-4788-834F-5ECF52944660@sandoe.co.uk> References: <77197F1C-5183-4F12-8701-83ACFF5FC96F@sandoe.co.uk> To: Alex Coplan X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 again, thanks for working on this and for fixing the SDK blocker. > On 20 Jun 2023, at 13:30, Alex Coplan wrote: >=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). 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). >> (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? 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: >>=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. 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