When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
This patch delays the removal of redundant isolation for inferred
global-actor isolation to Swift 6 too, since we only warn about it
changing in Swift 5. Otherwise, only isolation that is a byproduct
of inference no longer needs an await, which will probably confuse
people.
This change is with respect to SE-327, which argues that the
non-static stored properties of ordinary structs do not need
global-actor isolation.
If a struct is a property-wrapper, then global-actor isolation
still applies to the `wrappedValue`, even if it's a stored property.
This is needed in order to support the propagation of global-actor
isolation through the wrapper, even when the programmer has opted
to use a stored property instead of a computed one for the
`wrappedValue`. Since this propagation is a useful pattern, I think
this exception is reasonable.
This could happen previously when computing the existential type
for a given archetype. In cases where an archetype is only constrained
to a class, return the class type directly rather than wrapping it
in an existential type.
`shouldCoerceToContextualType` used `solution.getType(ASTNode)`
which returns a type that has type variables in it. To properly
check whether result type needs a coercion it has to be resolved
first which is done via `solution.getResultType(ASTNode)`.
Resolves: rdar://88285682
The current check in MiscDiagnostics can only handle local 2-cycles as in:
func foo() -> some P { return bar() }
func bar() -> some P { return foo() }
Larger cycles, such as the 3-cycle present in the validation test in this patch cannot be detected without resolving all substitutions up front. Therefore, we take the tact that we can at least prevent the compiler from crashing. At runtime, instead, type resolution will blow out the stack.
The check here is simple: Plumb through a set of opaque type decls that the resolution machinery has already seen, and if we encounter a recursive opaque type substitution bail with the original opaque type.
rdar://87121502
Verified that lexical lifetimes DO NOT result in a method call to a weak
reference resulting in a strong reference to the object. Consequently,
even with lexical lifetimes enabled, it is still possible, within a
single scope, for the first method call to an object weakly referenced
to occur but for the second such call not to because the object will
have been deallocated.
Verified that when a __consuming method calls a function which takes a
closure that captures self weakly, self is not deallocated until the
call returns. (Note that this is a behavioral change from what occurs
when lexical borrow scopes are disabled; in that case, self is
deallocated before the call to the function.)
