This is not supported for the same reason you can't have a noncopyable
variadic parameter, but the code was hard-coded to check for copyability
only.
Generalize this to apply the generic signature for Array via the
common code path, and add a custom note to explain why those requirements
are checked in the first place.
Cleaning this up also fixed some fuzzer crashes.
Reported on the forums:
https://forums.swift.org/t/variadic-escapable-arguments-crash-the-compiler/86727/2
If the argument was synthesized by the solver, let's fail. This can
happen when a parameter type is optional and (currently) inference
would try both optional and non-optional bindings for the new
argument which cases a mismatch in one of the conversion cases.
Resolves: https://github.com/swiftlang/swift/issues/88456
Resolves: rdar://174723056
Previously we would allow these in Sema and diagnose them in SILGen,
but allowing them in Sema is unsound because it means the constraint
system ends up kicking interface type requests for declarations that
should be type-checked as part of the closure itself. Adjust the
name lookup logic to look through parent closures when detecting
invalid forward references.
For now we don't fallback to an outer result on encountering a
use-before-declaration to preserve the current behavior. I'm planning
on changing that in the next commit though.
rdar://74430478
Missed this in my original Sendable-dependence patch, the sendability
of a closure can be dependent if its contextual type is. I'm not
sure this case ever actually matters in practice, but it seems like we
ought to be consistent with the existing logic and not have the
behavior be dependent on whether the dependence is evaluated before or
after the closure is resolved.
Completion can kick lazy type-checking for bindings, make sure we
decline to type-check in a closure since bindings cannot be
type-checked independently of their parent closure.
The erasing we're doing here is only for printing purposes, that
doesn't really matter for the replacement types and avoids running into
a crash where we incorrectly grab the wrong generic signature.
Looking up serialized extensions for a nested nominal type requires
computing its mangled name, which may kick semantic requests. Ensure
we don't do this for nominals in parsed SourceFiles such that we
don't end up kicking this during extension binding.
We've had a load-bearing optimization that avoids rebuilding
the generic signature of the protocol extension to avoid a
cycle involving a typealias in the extension that's mentioned
as a requirement in the protocol, for example:
```
public protocol P3 {
associatedtype A
}
public protocol P4: P3 where A == B {}
extension P4 {
public typealias B = String
}
```
What was happening is that we're inside a
StructuralRequirementsRequest, so we're performing TypeResolution
in the Structural stage. When we encounter this typealias that's
within a protocol extension, we'd end up accidentally requesting
the interface type of that alias through
`TypeChecker::substMemberTypeWithBase`
(via `aliasDecl->getUnderlyingType()`).
What we should do instead is call `aliasDecl->getStructuralType()`
and skip the substitution during that stage.
There happened to already be code doing this, but it was only
kicking in if the DeclContext `isa<ProtocolDecl>`, which excludes
extensions of a protocol. I see no reason why extensions of a
protocol should be excluded, so I assume it was unintentional.
Thus, the fix boils down to using `DeclContext::getSelfProtocolDecl`
which does include extensions of protocols. With this fix, the
optimization is no longer load-bearing on the example above.
See the history of this hack in f747121080
or rdar://problem/129540617
Slava Pestov
Hamish Knight
Kavon Farvardin
Pavel Yaskevich