The logic that computes whether a decl is unavailable at runtime was allowing
`@available` attributes for specific availability domains override
`@available(*, unavailable)`. Universally unavailable decls are always
unavailable, regardless of their other `@available` attributes.
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.
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.
The version remapping for `@backDeployed` regressed due to a bug introduced by
https://github.com/swiftlang/swift/pull/81922.
Also, fix some visionOS tests that have gotten out of date because we don't
seem to be running them in CI.
Resolves rdar://152542983.
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.
Implements SE-0460 -- the non-underscored version of @specialized.
It allows to specify "internal" (not abi affecting) specializations.
rdar://150033316
The changes in https://github.com/swiftlang/swift/pull/80040 caused the
compiler to start diagnosing extensions containing only members that are
either `@_spi`, `@_alwaysEmitIntoClient`, or unavailable when the
`-require-explicit-availability` flag is passed. Extensions should not be
diagnosed when they only contain members that would not be diagnosed
themselves.
Resolves rdar://148275432.
ABI-only declarations now inherit `@available`, `@backDeployed`, etc. from their ABI counterpart. This will make it unnecessary to specify these attributes in `@abi`. Also some changes to make sure we suggest inserting `@available` in the correct place.
No tests because the enforcement is not yet in.
https://github.com/swiftlang/swift/pull/79807 caused a regression in which
`AvailabilityContext` stopped tracking the available version range for the
active platform domain for certain platforms. Fix this by reverting to checking
`AvailabilityDomain::isActive()` to determine when a given platform
`AvailabilityDomain` represents the target platform. The compiler's existing
mapping from target triple to platform domain is incomplete and it's not clear
to me whether fixing that could cause other regressions.
Resolves rdar://147413616.
Regardless of the value specified for `-unavailable-decl-optimization`, decls
that are unavailable in custom availability domains should be treated as always
unreachable at runtime.
Part of rdar://138441307.
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.
Store `CustomAvailabilityDomain` instances in a folding set on `ASTContext`.
This instances of custom domains to be created without needing to cache them in
disparate locations.
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.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
Introduce a constructor that takes an `llvm::VersionTuple` directly, instead of
needing to spell out `VersionRange::allGTE(<tuple>)` which is unnecessarily
verbose.
Introduce `SemanticAvailableAttr` conveniences to compute the deprecated and
obsoleted ranges for an attribute and ensure they remap versions when needed.
This simplifies the code to emit availabilty diagnostics and ensures that they
display domain names consistently. While updating existing diagnostics, improve
consistency along other dimensions as well.
Delay resolution of availability domain identifiers parsed in availability
specifications until type-checking. This allows custom domain specifications to
be written in `if #available` queries.
Implement lookup of availability domains for identifiers on
`AvailabilityDomainOrIdentifier`. Add a bit to that type which represents
whether or not lookup has already been attempted. This allows both
`AvailableAttr` and `AvailabilitySpec` to share a common implementation of
domain lookup.
Translate macOS 10.16 to macOS 11 on-demand when calling
`SemanticAvailableAttr` version accessors. This removes the need for
`AvailableAttr` to have mutable version members that
`SemanticAvailableAttrRequest` can update.
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.
Using availability domains, reimplement the algorithm that determines whether a
declaration is unavailable at runtime. The new algorithm takes ABI compatible
platforms into account, ensuring that declarations that are available on iOS do
not get treated as unreachable at runtime when compiling for visionOS.
Resolves rdar://116742214.
When diagnosing a declaration that is more available than its context, to
preserve source compatibility we need to downgrade the diagnostic to a warning
when the outermost declaration is an extension. This logic regressed with
https://github.com/swiftlang/swift/pull/77950 and my earlier attempt to fix
this (https://github.com/swiftlang/swift/pull/78832) misidentified what had
regressed.
Really resolves rdar://143423070.
In https://github.com/swiftlang/swift/pull/78454 queries for the platform
availability of decl were consolidated into
`Decl::getAvailableAttrForPlatformIntroduction()`. In addition to checking the
attributes directly attached to the decl, this method also checks whether the
decl is a member directly contained inside of an extension and checks for
attributes attached to the extension as well. Previously, this logic was only
used for availability checking diagnostics, where special casing extension
members was a requirement. As a result of the consolidation, though, the logic
is now also shared by the query that determines whether to weakly link symbols
associated with a decl. That determination already had its own way of handling
members of extensions but it seemed like consolidating the logic would stil be
a net improvement that would reduce overall complexity.
Unfortunately, the existing approach to getting the availability of the
enclosing extension had a subtle bug for both AccessorDecl and OpaqueTypeDecl.
If an AvailableAttr was not directly attached to the immediate decl, then
`Decl::getAvailableAttrForPlatformIntroduction()` would check if the enclosing
decl context was an extension and look at its attributes as well. For
AccessorDecl and OpaqueTypeDecl, checking the enclosing decl context would
accidentally skip over the VarDecl and AbstractFunctionDecl that are formally
the parents of those decls for the purposes of attribute inheritance. As a
result, the availability of the enclosing property or function could be ignored
if the enclosing extension had explicit availability attributes.
The fix is to use `AvailabilityInference::parentDeclForInferredAvailability()`
instead of `getDeclContext()` when looking for the immediately enclosing
extension.
Resolves rdar://143139472.
