cyndyishida wrote: > Overall I really like the direction of this. I'm curious if any of the > maintainers from Apple have thoughts since they're the primary users of > availability annotations.
While I like the approach of aligning availability parameters closer to `llvm::Triple`, I am concerned about how this will interact with existing precedent. There is a lot of code that passes in _platform_ values that aren't actually `OSType`. For example `__attribute__((availability(macCatalyst, ...))` aligns to `EnviornmentType::MacABI` and `__attribute__((availability(macOSApplicationExtension, ...)))` aligns to cli args `-mtargetos=macos -fapplication-extension`. It may become difficult to maintain the distinction between what is accepted as a `platform` vs a `environment`. And we can't realistically re-write client code relying on this. This attribute behavior also aligns very closely with Swift's `@available` Would it be possible to similarly treat the target shader stages & combinations as platform values as well? Or define a new attribute that does not conflict. https://github.com/llvm/llvm-project/pull/89809 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
