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