Expressions that failed type-check can't be correctly analyzed by
effects checker due to missing type and overload choice information.
Resolves: rdar://76475495
If `async` effect has been inferred from the body of the closure,
let's find out the first occurrence of `async` node and point it out
to make it clear why closure is `async`.
Resolves: rdar://70610141
canImport should be able to take an additional parameter labeled by either version or
underlyingVersion. We need underlyingVersion for clang modules with Swift overlays because they
have separate version numbers. The library users are usually interested in checking the importability
of the underlying clang module instead of its Swift overlay.
Part of rdar://73992299
- Introduce an UnownedSerialExecutor type into the concurrency library.
- Create a SerialExecutor protocol which allows an executor type to
change how it executes jobs.
- Add an unownedExecutor requirement to the Actor protocol.
- Change the ABI for ExecutorRef so that it stores a SerialExecutor
witness table pointer in the implementation field. This effectively
makes ExecutorRef an `unowned(unsafe) SerialExecutor`, except that
default actors are represented without a witness table pointer (just
a bit-pattern).
- Synthesize the unownedExecutor method for default actors (i.e. actors
that don't provide an unownedExecutor property).
- Make synthesized unownedExecutor properties `final`, and give them
a semantics attribute specifying that they're for default actors.
- Split `Builtin.buildSerialExecutorRef` into a few more precise
builtins. We're not using the main-actor one yet, though.
Pitch thread:
https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425
Implicitly-generated interpolation variables are mutated within the
autoclosures created by a `spawn let`. Don't complain about them being
concurrently accessed, because they aren't.
Fixes rdar://76020473.
In order to allow LLDB to evaluate expressions inside an actor without spawining
async functions and potentially continue all threads, this relaxes the actor
isolation checks in @LLDBDebuggerFunction functions to allow a synchronous call
into an extension method.
rdar://75905336
Asking for Sendable conformances on this path is going to lead to
a traversal of the stored properties of the type. If there is an
interface type computation ongoing, as is very likely the case, this
traversal can wind up causing a cycle when it forces the interface type
of a member once again.
Request only the non-structural conformances to break the cycle.
rdar://77189542
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
mismatch.
If there's an error in property wrapper application, the backing property
wrapper type request will return a null type, which would cause the compiler
to crash because most error recovery code expects ErrorType. If the wrapper
application has an error, use the interface type of the parameter instead.
In the following test case, we are crashing while building the generic signature of `someGenericFunc`, potentially invoked on `model` in line 11.
```swift
struct MyBinding<BindingOuter> {
func someGenericFunc<BindingInner>(x: BindingInner) {}
}
struct MyTextField<TextFieldOuter> {
init<TextFieldInner>(text: MyBinding<TextFieldInner>) {}
}
struct EncodedView {
func foo(model: MyBinding<String>) {
let _ = MyTextField<String>(text: model)
}
}
```
Because we know that `model` has type `MyBinding<TextFieldInner>`, we substitute the `BindingOuter` generic parameter by `TextFieldInner`. Thus, `someGenericFunc` has the signature `<TextFieldInner /* substitutes BindingOuter */, BindingInner>`. `TextFieldInner` and `BindingOuter` both have `depth = 1`, `index = 0`. Thus the verification in `GenericSignatureBuilder` is failing.
After discussion with Slava, the root issue appears to be that we shouldn’t be calling `subst` on a `GenericFunctionType` at all. Instead we should be using `substGenericArgs` which doesn’t attempt to rebuild a generic signature, but instead builds a non-generic function type.
--------------------------------------------------------------------------------
We slightly regress in code completion results by showing two `collidingGeneric` twice in the following case.
```swift
protocol P1 {
func collidingGeneric<T>(x: T)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
Previously, we were representing the type of `collidingGeneric` by a generic function type with generic param `T` that doesn’t have any restrictions. Since we are now using `substGenericArgs` instead of `subst`, we receive a non-generic function type that represents `T` as an archetype. And since that archetype is different for the two function signatures, we show the result twice in code completion.
One could also argue that showing the result twice is intended (or at least acceptable) behaviour since, the two protocol may name their generic params differently. E.g. in
```swift
protocol P1 {
func collidingGeneric<S>(x: S)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
we might be expected to show the following two results
```
func collidingGeneric<S>(x: S)
func collidingGeneric<T>(x: T)
```
Resolves rdar://76711477 [SR-14495]
Not-filtering solutions causes unacceptable slownesses in some cases.
For now, filter solutions as normal typechecking does to restore the
performance.
rdar://76714968
Consider the following example.
```swift
protocol FontStyle {}
struct FontStyleOne: FontStyle {}
extension FontStyle where Self == FontStyleOne {
static var one: FontStyleOne { FontStyleOne() }
}
func foo<T: FontStyle>(x: T) {}
func case1() {
foo(x: .#^COMPLETE^#)
}
```
With SE-0299 accepted, we should be suggesting `.one`.
For that, we need to consider the extension applied when performing the unresolved dot code completion with a primary archetype that conforms to `FontStyle`.
However, in the following case, which performs an unresolved dot completion on the same base type, we don't want to suggest `.one` because that would require `T == FontStyleOne`, which we can’t assume.
```swift
func case2<T: FontStyle>(x: T) {
x.#^COMPLETE_2^#
}
```
Since the constraint system cannot tell us how it came up with the archetype, we need to apply a heuristic to differentiate between the two cases.
What seems to work fine in most cases, is to determine if `T` referes to a generic parameter that is visible from the decl context we are completing in (i.e. the decl context we are completing in is a child context of the context that `T` is declared in). If it is not, then `T` cannot be the type of a variable we are completing on. Thus, we are in the first case and we should consider all extensions of `FontStyle` because we can further specialize `T` by picking a more concrete type.
Otherwise `T` may be the type of a variable we are completing on and we should be conservative and only suggest those extensions whose requirements are fulfilled by `T`.
Since this is just a heuristic, there are some corner cases, where we aren’t suggesting constrainted extensions although we should. For example, in the following example the call to `testRecursive` doesn’t use `T` and we should thus suggest `one`. But by the rules described above we detect that `T` is accessible at the call and thus don’t apply extension whose requirements aren’t satisfied.
```swift
func testRecursive<T: FontStyle>(_ style: T) {
testRecursive(.#^COMPLETE_RECURSIVE_GENERIC^#)
}
```
Similar completion issues also occurred without SE-0299 in more complicated, generic scenarios.
Resolves rdar://74958497 and SR-12973
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
