This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The original bug was a crash-on-invalid with a missing '}', but it
actually exposed a bug with nested protocols (SE-0404) and another
long-time bug.
- Whatever we do, we should skip this for protocols because their 'Self'
parameter is not bound from context.
- getTrailingWhereClause() is not the right proxy for "has a generic
signature different than its parent", in particular it doesn't
round-trip through serialization. Instead, just compare generic
signatures for pointer equality in the early return check.
The second change is source-breaking because it was possible to
write a nested type with a `where` clause and use it contradicting
its requirements across a module boundary.
Fixes rdar://113103854.
If the pattern doesn't have any pack parameters in it anymore,
we need to recover the substituted count type from the original
count type.
Fixes rdar://problem/112065340.
Currently solver picks the first conjunction it can find,
which means - the earliest resolved closure. This is not
always correct because when calls are chained closures
passed to the lower members could be resolved sooner
than the ones higher up but at the same time they depend
on types inferred from members higher in the chain.
Let's make sure that multi-statement closures are always
solved in order they appear in the AST to make sure that
types are available to members lower in the chain.
getContextSubstitutionMap() builds a substitution map for the generic signature of
the parent context, which is wrong if the typealias has its own 'where' clause.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
If the type of an `ExplicitCastExpr` is not valid, it is a null type, which causes a crash when checking if the cast type has parameterized existentials.
rdar://95629905
We can't just ignore unavailable conformances because the
generic signature we're computing might itself be attached
to an unavailable declaration.
Until we get a proper fix, only drop unavailable conformances
to Sendable here.
Fixes rdar://problem/94305457.
We would like to leave room in the language for `some` types in existential
constraints a la `any P<some Q>` to resolve as a part of the requirement
signature of a future generalized existential type. To that end, usages of
`some` types nested anywhere in the arguments of an existential will fail to
resolve.
rdar://92758884
