`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`.
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 will unblock parsing and type-checking availability queries that specify
custom availability domains, e.g.:
```
if #available(CustomDomain) {
// Use declarations protected by @available(CustomDomain)
}
```
Implement lookup of availability domains for identifiers on
`AvailabilityDomainOrIdentifier`. Add a bit to that type which represents
whether or not lookup has already been attempted. This allows both
`AvailableAttr` and `AvailabilitySpec` to share a common implementation of
domain lookup.
In order to unblock resolution of availability domains during type-checking
instead of parsing, diagnostics about missing or superfluous wildcards in
availability specification lists need to move to Sema.
According to the proposal both variants cannot be used together
with other forms of isolation i.e. isolated parameters, global
actors, `@isolated(any)` attributes.
Switch to calling `swift::getAvailabilityConstraintsForDecl()` to get the
unsatisfied availability constraints that should be diagnosed.
This was intended to be NFC, but it turns out it fixed a bug in the recently
introduced objc_implementation_direct_to_storage.swift test. In the test,
the stored properties are as unavailable as the context that is accessing them
so the accesses should not be diagnosed. However, this test demonstrates a
bigger issue with `@objc @implementation`, which is that it allows the
implementations of Obj-C interfaces to be less available than the interface,
which effectively provides an availability checking loophole that can be used
to invoke unavailable code.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
When diagnosing a declaration that is more available than its context, to
preserve source compatibility we need to downgrade the diagnostic to a warning
when the outermost declaration is an extension. This logic regressed with
https://github.com/swiftlang/swift/pull/77950 and my earlier attempt to fix
this (https://github.com/swiftlang/swift/pull/78832) misidentified what had
regressed.
Really resolves rdar://143423070.
Specifically, we were attempting to diagnose cases like the following:
```swift
@MainActor protocol P {
func foo() async
}
struct S : P {
@execution(concurrent) func foo() async {}
}
```
This was just an attempt to be more conservative. After some conversations, it
came up that nonisolated does not work that way... that is the compiler will
accept the following and just hop in the protocol witness thunk:
```swift
@MainActor protocol P {
func foo() async
}
struct S : P {
nonisolated func foo() async {}
}
```
This never belonged in ActorIsolationRequest since it fits perfectly in the
attribute checker. This also simplifies the logic before I add code to
getIsolationFromAttribute to handle ExecutionAttribute.
When a method override is as available as the class it's a member of, then it
can't be any more available. It doesn't make sense to diagnose such a method as
less available than the method it overrides. This regressed recently for
methods belonging to classes that are nested inside extensions. The
availability of the derived class may be defined by its context, but the
compiler was only checking the availability attributes directly on the class.
Resolves rdar://143600638.
Downgrade the `cannot be more available than enclosing scope` error to a
warning when the attribute making the decl too available is specified for a
less specific platform.
Resolves rdar://143423070.
This diagnostic was staged in
https://github.com/swiftlang/swift/pull/38991 as a warning to not break
source. Give it a reasonable margin and, in turn, convey that it is in
fact a compatibility warning and will become an error.
