Add support for the `Swift` availability domain, which represents availability
with respect to the Swift runtime. Use of this domain is restricted by the
experimental feature `SwiftRuntimeAvailability`.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Accessor availability diagnostics for key path expressions were first
introduced by https://github.com/swiftlang/swift/pull/83931. Those changes were
insufficient because sometimes key path expressions are generated in the AST
with more mutability than is needed by the context and so setter availability
could be diagnosed inappropriately. Key path expression binding was refined in
https://github.com/swiftlang/swift/pull/84491 to make this less likely to
occur. However, there are still some circumstances in which a mutable key path
is generated in the AST and then immediately coerced into an immutable key path
to satisfy the contextual type. This change infers the immutability of these key
path expressions by looking through surrounding conversion expressions.
An always enabled availability domain is implicitly available in all contexts,
so uses of declarations that are marked as `@available` in the domain are never
rejected. This is useful for an availability domain representing a feature flag
that has become permanently enabled.
Partially resolves rdar://157593409.
Diagnose the availability of the specific accessors that are referenced
implicitly via a key path reference. This causes setter availability to be
diagnosed when passing a key path to a function that takes a `WritableKeyPath`.
Resolves rdar://157232221.
Previously, whether a declaration is unavailable because it is obsolete was
determined based solely on the deployment target and not based on contextual
availability. Taking contextual availability into account makes availability
checking more internally consistent and allows library authors to evolve APIs
by obsoleting the previous declaration while introducing a new declaration in the
same version:
```
@available(macOS, obsoleted: 15)
func foo(_ x: Int) { }
@available(macOS, introduced: 15)
func foo(_ x: Int, y: Int = 0) { }
foo(42) // unambiguous, regardless of contextual version of macOS
```
This change primarily accepts more code that wasn't accepted previously, but it
could also be source breaking for some code that was previously allowed to use
obsoleted declarations in contexts that will always run on OS versions where
the declaration is obsolete. That code was clearly taking advantage of an
availabilty loophole, though, and in practice I don't expect it to be common.
Resolves rdar://144647964.
It caused a regression when building the CloudKit module from its interface in
the Xcode 26 SDKs.
This effectively reverts https://github.com/swiftlang/swift/pull/83384 (though
a few parts of that PR that did not cause any regressions have been kept).
Resolves rdar://157342004.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
Previously, whether a declaration is unavailable because it is obsolete was
determined based solely on the deployment target and not based on contextual
availability. Taking contextual availability into account makes availability
checking more internally consistent and allows library authors to evolve APIs
by obsoleting the previous declaration while introducing a new declaration in the
same version:
```
@available(macOS, obsoleted: 15)
func foo(_ x: Int) { }
@available(macOS, introduced: 15)
func foo(_ x: Int, y: Int = 0) { }
foo(42) // unambiguous, regardless of contextual version of macOS
```
This change primarily accepts more code that wasn't accepted previously, but it
could also be source breaking for some code that was previously allowed to use
obsoleted declarations in contexts that will always run on OS versions where
the declaration is obsolete. That code was clearly taking advantage of an
availabilty loophole, though, and in practice I don't expect it to be common.
Resolves rdar://144647964.
Protocol requirement witnesses cannot only be available in a custom
availability domain if the requirement does not have the same availability
constraint.
Resolves rdar://156462516.
Use these queries to replace some duplicated code. Also, move the
`attr_inlinable_available.swift` test to the `Availability` sub-directory since
the test has more to do with availability checking than it has to do
specifically with the `@inlinable` attr.
In implicit contexts that are universally unavailable, allow writable key paths
to be formed to properties with setters that are also marked as universally
unavailable. This fixes a regression from the previous commit where the code
synthesized for `@Observable` properties in universally unavailable classes was
rejected by the availability checker.
Previously, only conditional unavailability was considered, but setters that
are always unavailable must also make a keypath read-only.
Resolves rdar://155832511.
Serialization and IRGen don't yet support opaque return types that would depend
on querying availability of a custom domain so we need to reject this code to
avoid mis-compiling it.
