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.
For declarations that aren't in source files there isn't an `AvailabilityScope`
tree to consult to find their `AvailabilityContext`. The fallback mechanism
used by `AvailabilityContext::forLocation()` walks up the `DeclContext`
hierarchy to build up the context for implicit code but this isn't entirely
correct since it skips over certain kinds of decls (like property
declarations). Instead, we need to walk up the parent decl hierarchy that is
used for availability inference to ensure that no decls with relevant
availability attributes are skipped.
It had a bug that would cause it to return incorrect results for some decls
with invalid source locations. Since not all declarations introduce a new
`DeclContext`, it's not sufficient to walk the decl context hiearchy when
computing availability for a decl.
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.
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.
This makes more efficient use of the permanent memory allocated for
`AvailabilityContext` representations and also fixes a leak that was introduced
in https://github.com/swiftlang/swift/pull/79718 where the small vector for
unavailable domain storage was not being cleaned up on `ASTContext`
deallocation.
Resolves rdar://145929932.
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).
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.
Call `swift::getAvailabilityConstraintsForDecl()` to gather the constraints
that should be added to an AvailabilityContext when constraining it to the
availability of a given declaration.
Now that most of the compiler tracks availability in terms of
AvailabilityDomain, it's time to do so in AvailabilityContext as well. This
will ensure that the compiler accurately suppresses diagnostics about a decl
being unavailable in an arbitrary domain when the context of the use is already
unavailable in that domain.
With this change, most of the special-casing for the Embedded Swift availability
domain has been removed from the compiler, outside of parsing and interface
printing.
Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
When a declaration is `@unsafe`, don't emit strict safety diagnostics
for uses of unsafe entities, constructs, or types within it. This
allows one to account for all unsafe behavior in a module using strict
memory safety by marking the appropriate declarations `@unsafe`.
Enhance the strict-safety diagnostics to suggest the addition of
`@unsafe` where it is needed to suppress them, with a Fix-It. Ensure
that all such diagnostics can be suppressed via `@unsafe` so it's
possible to get to the above state.
Also includes a drive-by bug fix where we weren't diagnosing unsafe
methods overriding safe ones in some cases.
Fixes rdar://139467327.
It replaces `DeclAttr::getUnavailable()` and `AvailableAttr::isUnavailable()`
as the designated way to query for the attribute that makes a decl unavailable.
Treat `@_unavailableInEmbedded` as if it were `@available(Embedded,
unavailable)` and apply platform compatibility logic in the availability
checker. Revert back to disallowing calls to universally unavailable functions
(`@available(*, unavailable)`) in all contexts.
Implement a query that returns the `AvailabilityContext` for a given
`SourceLoc` and `DeclContext`. Re-implement the existing type checker query
that just returns an `AvailabilityRange` on top of the new query.
Make the pointer to uniqued storage an implementation detail of an
`AvailabilityContext` value. This way clients of `AvailabilityContext` don't
need to think about pointers and can have access to mutating operations on a
context when appropriate.
