llvm-beanz wrote: > 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`.
`macCatalyst` would work perfect with the new structure because the platform is `iOS` and the environment is `macabi` (or you could change the string to `catalyst`. App extensions are kinda a weird case because on the one hand, the compiler largely doesn't need to know about them (except for availability), but they drive linking differently. > 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. I wouldn't expect rewriting existing code. The new argument added in this PR is optional, so you can use it or not. It seemed like it had the possibility to simplify the use cases. For example, if `app_extension` were an environment you wouldn't need to add multiple new platform cases for each new platform. For us this is a big deal because we effectively have 16 environments that are basically all supported across 2 platforms (shader model and Vulkan). > 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. It would be preferable for us to separate environment and platform, but that doesn't mean Apple needs to. I think you should consider it because it is a more forward looking and maintainable approach, but I don't think there is any reason why we can't add this argument field while Apple continues to only support the legacy platform strings. 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
