[Concurrency][Stdlib] Add SwiftStdlibCurrentOS availability, use it. #81440
Conversation
al45tair
requested review from
etcwilde,
justice-adams-apple,
shahmishal,
ktoso,
a team,
edymtt and
compnerd
as code owners
If you use SwiftStdlibCurrentOS availability, you will be able to use new types and functions from within the implementation. This works by, when appropriate, building with the CurrentOS availability set to the current deployment target. rdar://150944675
al45tair
force-pushed
the
currentos-availability
branch
from
d36db74 to
28f96e6
Compare
|
@swift-ci Please test |
|
Love where this is going, but I think the names are more-or-less backwards; we shouldn't reference the "OS" for changes that are just new API additions in the stdlib at all. They should be "SwiftStdlib x.y," and the rare change that does depend on an outside OS feature should either reference the OS version, or reference the feature itself (Foundation does this). This may make phasing adoption in slightly more complex however. |
| @@ -36,3 +36,26 @@ if(NOT SwiftCore_ARCH_SUBDIR) | |||
|
|
|||
| message(CONFIGURE_LOG "Swift Arch: ${arch}") | |||
| endif() | |||
|
|
|||
| if(NOT SwiftCore_SWIFT_AVAILABILITY_PLATFORM) | |||
| set(availability_platform_macosx "macOS") | |||
There was a problem hiding this comment.
I don't love this bit. We're trying to get away from the hard-coded hand-maintained tables. I wonder if there is any way we could embed it into the existing availability macro file?
CC @compnerd, do you have any ideas?
Maybe this is something we can embed in cache files?
There was a problem hiding this comment.
CPP to generate a response file would be my recommendation. I think that we were already doing that somewhere? (Perhaps the new build system?)
| set(availability_platform_bridgeos "bridgeOS") | ||
|
|
||
| if(SwiftCore_SWIFT_MODULE_TRIPLE MATCHES ".*-([^-]+)-simulator$") | ||
| set(platform "${CMAKE_MATCH_1}") |
There was a problem hiding this comment.
I think you should be able to get this information from the platform entry in the target info without needing to regex it out of the module triple.
| # ON will cause us to use the "proper" availability instead. | ||
| string(REPLACE "SwiftStdlib" "SwiftStdlibCurrentOS" current "${def}") | ||
| if(NOT SwiftCore_ENABLE_STRICT_AVAILABILITY AND SwiftCore_SWIFT_AVAILABILITY_PLATFORM) | ||
| string(REGEX MATCH "${SwiftCore_SWIFT_AVAILABILITY_PLATFORM} ([0-9]+(\.[0-9]+)+)" platform_version "${def}") |
There was a problem hiding this comment.
AvailabilityMacros.cmake is loaded before platform info, so SwiftCore_SWIFT_AVAILABILITY_PLATFORM won't be set by that here.
Agreed, but I didn't want to change the meaning of We could make changing the names a separate task, if someone comes up with something better. |
If you use
SwiftStdlibCurrentOSavailability, you will be able to use new types and functions from within the implementation. This works by, when appropriate, building with theCurrentOSavailability set to the current deployment target.rdar://150944675