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.
Refactors `@_dynamicReplacement` attribute verification to consider
only exact matches first, and if there are none, attempt to strip
away sendability on ObjC declarations to make sure that any new
`@Sendable` or `any Sendable` introduced to `@precocurrency` declarations
don't break the overload selection.
Witness checking itself is allowed to skip `@Sendable` mismatch in this
situation. This is a narrow fix for `SendableCompletionHandlers` feature
to make sure that the behavior doesn't change for non-ObjC witnesses
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.
This is a stop-gap solution to prevent spurious warnings when "unsafe"
expressions and for..in loops are used without strict memory safety.
The full answer is probably to determine where unsafe code is all the time,
so that we can still (correctly) diagnose "no unsafe operations" even outside
of strict memory safety mode.
With the acceptance of SE-0458, allow the use of unsafe expressions, the
@safe and @unsafe attributes, and the `unsafe` effect on the for..in loop
in all Swift code.
Introduce the `-strict-memory-safety` flag detailed in the proposal to
enable strict memory safety checking. This enables a new class of
feature, an optional feature (that is *not* upcoming or experimental),
and which can be detected via `hasFeature(StrictMemorySafety)`.
