The attribute makes the declaration unavailable from the perspective of clients
of the module's public interface and was creating a loophole that admitted
inappropriate unavailability.
Currently we handle CodingKeys synthesis in
`TypeChecker::lookupUnqualified`, make sure we do the same in
`TypeChecker::lookupUnqualifiedType`.
rdar://146055457
Historically, we've allowed protocol requirements to be written with
`@_spi_available` which makes them unavailable to clients of the public
`.swiftinterface`. Don't diagnose this when checking a `.swiftinterface` since
there's nothing the client can do about it.
Resolves rdar://146334181.
Transitively inferring a protocol type binding from a contextual
type means that the binding set for a leading-dot member reference
is complete because there could be no other sources of bindings
when expression is connected directly to a contextual type.
Resolves: rdar://145103149
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.
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
This is the missing check for "rule #1" in the isolated conformances proposal,
which states that an isolated conformance can only be referenced within
the same isolation domain as the conformance. For example, a
main-actor-isolated conformance can only be used within main-actor code.
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.
Within the constraint system, introduce a new kind of conformance constraint,
a "nonisolated conforms-to" constraint, which can only be satisfied by
nonisolated conformances. Introduce this constraint instead of the normal
conforms-to constraint whenever the subject type is a type parameter that
has either a `Sendable` or `SendableMetatype` constraint, i.e., when the type
or its values can escape the current isolation domain.
