If an obsoleted API is only called behind an availability check that is
never hit because it is unreachable for the current deployment target /
Swift version, it no longer errors.
Fixes https://github.com/swiftlang/swift/issues/88763
When emitting fix-its that would make an unavailable declaration available, use
`anyAppleOS` in the fix-it instead of the target platform if the unmet
availability constraint is in the `anyAppleOS` domain.
Resolves rdar://174558882.
Fix a Swift 6.3 regression in which extension members that are obsolete in the
current Swift language version are still considered available in contexts that
are also obsolete in the current Swift language version.
When computing the AvailabilityConstraints for a member of an extension,
constraints are first gathered for the member and then again for the extension
in case there are some attributes on the extension that should be effectively
inherited by the member. After gathering constraints, the core implementation
of `getAvailabilityConstraintsForDecl()` removes any constraints that can be
ignored in the given `AvailabilityContext`. That determination depends on the
kind of declaration the constraints are for, though, and it was being performed
first for the member on its own constraints and then again for the extension
for the combination of their constraints. This could result in member
constraints being ignored incorrectly.
The fix is to check whether a constraint ought to be ignored before adding it
to the set in the first place, rather than post-processing the entire
collection of constraints.
Resolves rdar://165942115.
Loosen availability checking to allow references to a decl that is unavailable
in a broader platform context in contexts which are unavailable in a more
specific platform context. For example, `@available(macOS, unavailable)` decls
should be allowed in `@available(macOSApplicationExtension, unavailable)`
contexts. This enhancement, which has always been desirable but wasn't high
priority, became more important with the introduction of `anyAppleOS`. Some
library authors may replace platform-specific availability annotations with
`anyAppleOS` availability and without this behavior change those attribute
updates would be source breaking.
Test updates assisted by claude.
Modeling the universal AvailabilityDomain as the bottom element of a lattice
containing all domains was useful for checking unavailability, but it makes
some other algorithms harder to write elegantly using availability domain
algebra. Instead, special case `*` in unavailability computations and only form
an availability domain lattice with the ABI stable platform domains,
`anyAppleOS`, and `Swift`.
Since reparentable protocols can have less availability
than the protocols inheriting from it, we need to first
loosen availability checking inheritance clauses to allow
for the statement of retroactive refinement.
Then, we need to tighten it in other places in terms of
expression checking, because we now cannot refer to
members of a generic type that originate from an unavailable
ancestor of a protocol to which the value conforms. Previously
it was not possible for that to be the case, so no checking
was performed.
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`.
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.
In anticipation of needing to compute runtime unavailability to determine
whether declarations should be printed in swiftinterfaces, factor out the code
that computes runtime unavailability into a shared utility based on
`DeclAvailabilityConstraints`.
NFC.
It must be possible to disambiguate overloads using the module-wide Swift
language version, even in contexts that are themselves obsolete in the current
Swift language version.
Resolves rdar://158620835.
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.
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.
When compiling for visionOS, iOS availability attributes are remapped into the
visionOS availability domain automatically. While the version remapping was
being performed correctly, there was a regression that caused the platform name
to be printed incorrectly in many diagnostics. Whenever an iOS version is
remapped to a visionOS version, availability diagnostics will now present
those versions as visionOS versions instead of iOS versions.
Resolves rdar://146293165.
Potential unavailability of a declaration has always been diagnosed in contexts
that do not have a sufficient platform introduction constraint, even when those
contexts are also unavailable on the target platform. This behavior is overly
strict, since the potential unavailability will never matter, but it's a
longstanding quirk of availability checking. As a result, some source code has
been written to work around this quirk by marking declarations as
simultaneously unavailable and introduced for a given platform:
```
@available(macOS, unavailable, introduced: 15)
func unavailableAndIntroducedInMacOS15() {
// ... allowed to call functions introduced in macOS 15.
}
```
When availability checking was refactored to be based on a constraint engine in
https://github.com/swiftlang/swift/pull/79260, the compiler started effectively
treating `@available(macOS, unavailable, introduced: 15)` as just
`@available(macOS, unavailable)` because the introduction constraint was
treated as lower priority and therefore superseded by the unavailability
constraint. This caused a regression for the code that was written to work
around the availability checker's strictness.
We could try to match the behavior from previous releases, but it's actually
tricky to match the behavior well enough in the new availability checking
architecture to fully fix source compatibility. Consequently, it seems like the
best fix is actually to address this long standing issue and stop diagnosing
potential unavailability in unavailable contexts. The main risk of this
approach is source compatibility for regions of unavailable code. It's
theoretically possible that restricting available declarations by introduction
version in unavailable contexts is important to prevent ambiguities during
overload resolution in some codebases. If we find that is a problem that is too
prevalent, we may have to take a different approach.
Resolves rdar://147945883.
Generalize the implementation of `SemanticDeclAvailabilityRequest` in
preparation for adding a new case to `SemanticDeclAvailability`. Use the
centralized availability constraint query instead of implementing a bespoke
algorithm for gathering constraints. Simplify `SemanticDeclAvailability` by
removing a case that is no longer relevant.
Part of rdar://138441307.
Introduction, deprecation, and obsoleteion ranges should only be returned by
the accessors on `SemanticAvailableAttr` when the attribute actually has an
affect on the corresponding kind of availability.
Choose names that don't imply availability is versioned, since custom
availability will support domains that are version-less (they are simply
available or unavailable).
Introduce `SemanticAvailableAttr` conveniences to compute the deprecated and
obsoleted ranges for an attribute and ensure they remap versions when needed.
When building up AvailabilityContexts, we assume that all of the enclosing
decls have already been accounted for in the AvailabilityContext that we are
constraining. Therefore, it doesn't make sense to merge availability
constraints from the enclosing extension of the target decl.
Switch to calling `swift::getAvailabilityConstraintsForDecl()` to get the
unsatisfied availability constraints that should be diagnosed.
This was intended to be NFC, but it turns out it fixed a bug in the recently
introduced objc_implementation_direct_to_storage.swift test. In the test,
the stored properties are as unavailable as the context that is accessing them
so the accesses should not be diagnosed. However, this test demonstrates a
bigger issue with `@objc @implementation`, which is that it allows the
implementations of Obj-C interfaces to be less available than the interface,
which effectively provides an availability checking loophole that can be used
to invoke unavailable code.
This new query is designed to become the canonical source of information
regarding whether a declaration is available to use in a given
`AvailabilityContext`. It should be adopted as the foundational building block
for all other queries that answer more specific questions about the
availability of a specific delcaration.
The implementation of this query has been copied from a variety of sources
which should eventually be deleted once the new query has been fully adopted.
NFC.
Allan Shortlidge
Keith Smiley
Kavon Farvardin