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.
