If the substitution terms of a concrete type symbol contain unresolved
name symbols, we have an invalid requirement that is dropped from the
minimized signature. In this case, the rewrite system used for minimization
cannot be installed as the official rewrite system for this generic
signature, because building a rewrite system from the signature will
produce a different result.
This might be the cause of the crash in rdar://114111159.
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 progress on variadic generics means we can now implement useful
witnesses in a tuple conformance. The feature remains very incomplete
though, today we crash in SILGen.
We want `T.A == U.B` to imply `shape(T) == shape(U)` if T (and thus U)
is a parameter pack.
To do this, we introduce some new rewrite rules:
1) For each associated type symbol `[P:A]`, a rule `([P:A].[shape] => [P:A])`.
2) For each non-pack generic parameter `τ_d_i`, a rule `τ_d_i.[shape] => [shape]`.
Now consider a rewrite rule `(τ_d_i.[P:A] => τ_D_I.[Q:B])`. The left-hand
side overlaps with the rule `([P:A].[shape] => [shape])` on the term
`τ_d_i.[P:A].[shape]`. Resolving the overlap gives us a new rule
t_d_i.[shape] => T_D_I.[shape]
If T is a term corresponding to some type parameter, we say that `T.[shape]` is
a shape term. If `T'.[shape]` is a reduced term, we say that T' is the reduced
shape of T.
Recall that shape requirements are represented as rules of the form:
τ_d_i.[shape] => τ_D_I.[shape]
Now, the rules of the first kind reduce our shape term `T.[shape]` to
`τ_d_i.[shape]`, where `τ_d_i` is the root generic parameter of T.
If `τ_d_i` is not a pack, a rule of the second kind reduces it to `[shape]`,
so the reduced shape of a non-pack parameter T is the empty term.
Otherwise, if `τ_d_i` is a pack, `τ_d_i.[shape]` might reduce to `τ_D_I.[shape]`
via a shape requirement. In this case, `τ_D_I` is the reduced shape of T.
Fixes rdar://problem/101813873.
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
Now that `InferredGenericSignatureRequest` creates
`StructuralRequirement`s from of the generic signature with valid source
locations, additional redundancy warnings are produced. Update tests
with the new warnings.
`InferredGenericSignatureRequest` creates `StructuralRequirement`s for
the requirements of the generic signature that is passed to it (if one
is).
Previously, it used invalid `SourceLoc`s for these requirements. The
result was that when errors that were emitted as a result of those
`StructuralRequirement`s (during concrete type contraction), they would
also have invalid `SourceLoc`s. The effect was that those errors were
ignored during `diagnoseRequirementErrors`.
Here, use the available loc for those requirements.
rdar://108963047
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
Generic arguments types are not always resolved enough to enable
aggregated mismatch fixes, which means that the solver should be
able to handle standalone generic argument matching constraints
and create a fix per mismatch location to coalesce them during
diagnostics.
Resolves: rdar://106054263
getContextSubstitutionMap() builds a substitution map for the generic signature of
the parent context, which is wrong if the typealias has its own 'where' clause.
getInheritedProtocols() skips type resolution and directly resolves
TypeReprs to TypeDecls.
On the other hand, when building a protocol requirement signature,
we use type resolution to resolve inheritance clause entries so
that we can properly support parameterized protocol types, and
protocol compositions that contain classes.
Since a TypeRepr with an invalid sub-component resolves to an
ErrorType, this meant that in invalid code, the first list of
protocols might contain protocols that don't appear in the second.
This broke rewrite system invariants. Fix this by checking if
type resolution failed when building the requirement signature of
a protocol, and if so, also look at getInheritedProtocols().
Fixes https://github.com/apple/swift/issues/61020.
