Since resolving the domain of an `@available` attribute is done during type
checking now, diagnostics about unexpected versions for a domain need to be
emitted at that point instead of during parsing. It doesn't make sense to
maintain the special version of this diagnostic that is emitted during parsing
for the universal availability domain only.
SourceKit-LSP tests depend on the exact behavior of this diagnostic (which I
don't plan to preserve) so I'm reverting the consolidation temporarily to get
unblocked.
If a type alias in generic context fixes all outer generic
parameters to concrete types, we allow the type alias to
be referenced without specifying the generic arguments of
its parent type.
However, we need to reduce the underlying type in case it
was written in terms of the (fully concrete) generic
parameters.
Fixes rdar://problem/143707820.
1. Non-actor initializers should participate in custom default isolation
inference. Otherwise, they will not be able to touch the type's stored
properties to initialize them if those properties have the default
isolation inferred.
2. All declarations inside actors and distributed actors do not participate
in default isolation inference; they remain unspecified, so the existing
isolation inference rules apply.
Ignore declarations that come from implicitly imported modules
when `MemberImportVisibility` feature is enabled otherwise
we might end up favoring an overload that would be diagnosed
as unavailable later.
Resolves: rdar://143582881
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.
They don't yield a correct error type as we didn't implement it, so
rather allow it and risk crashes, ban it until we get the time to
implement it.
The real solution is to adjust typed throws error inference to do an
union of the thrown error of the func and the type thrown by the
distributed actor system remote call -- which today always would be (E |
Error) -> Error...
We could add a new associated type to DAS and then we could make it more
proper...
resolves rdar://136467528
Checking whether a declaration is in a `.swiftinterface` is a very common query
that is made somewhat awkward because declarations are not always in source
files. To make these checks more ergonomic, expose a convenience on
DeclContext.
