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