Hi Iain, On 20/06/2023 15:08, Iain Sandoe wrote: > Hi Alex > > 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? 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 > >
