To avoid spurious diagnostics about unavailable operations when checking uses
of functions that take result builder closures, lookup of result builder
operations needs to ignore the restrictions of the `MemberImportVisibility`
feature. The result builder transform should simply use the operations that are
found and allow later checks to diagnose the use of inaccessible builder
operations.
Resolves rdar://144100445.
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
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.
