Note the test cases in abstract_type_witnesses used to pass but are now
rejected. This is fine, because doing anything more complicated used to
crash, and the GSB would crash or misbehave with these examples.
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
RequirementSignatureRequest
=> TypeAliasRequirementsRequest
=> isConstrainedExtension()
=> GenericSignatureRequest
=> RequirementSignatureRequest
Instead, use getTrailingWhereClause() as an approximation of
isConstrainedExtension().
Fixes rdar://problem/97236936.
Upgrade the diagnostic from one that mentions the restriction to one
that
1) Mentions primary associated types at all
2) Removes the constraints
3) Points at the declaration of the protocol type so the user can fix it
We don't care as much about rules with weird shapes as long
as they're LHS- or RHS-simplified, since the new minimal conformances
algorithm no longer relies on certain invariants.
Fixes rdar://problem/94746399.
In theory this is a source break if someone had a weird custom
conforming type, but I suspect in practice conformances to
this protocol are never defined.
The reason we want this requirement is that often you will see
code like the following:
protocol Point {
associatedtype Scalar: SIMDScalar
associatedtype Vector: SIMD where Vector.Scalar == Scalar
}
extension Point where Vector == SIMD2<Scalar> { ... }
When `Vector` is equated with `SIMD2<Scalar>`, we get an infinite
sequence of implied same-type requirements:
Vector.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == SIMD2<Scalar.MaskScalar.MaskScalar>
...
The protocol fails to typecheck with an error because the requirement
machine cannot build a rewrite system.
If SIMDScalar requires that MaskScalar.MaskScalar == MaskScalar, then
we instead get
Vector.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == SIMD2<Scalar.MaskScalar>
Vector.MaskStorage.MaskStorage == Vector.MaskStorage
...
Which ties off the recursion.
In theory, a more advanced implementation could represent this kind of
infinite recursion in 'closed form', but we don't have that yet, and I
believe adding this same-type requirement makes sense anyway.
Fixes rdar://problem/95075552.
We can end up with a rule that has a protocol symbol on the right hand side:
X.Y.Z => X.W.[P]
This will occur if X.W.[P] was obtained by simplifying a term X.W.U.V via
a rule (U.V => [P]), and before completion discovers a rule
(X.W.[P] => X.W).
Fixes rdar://problem/94854326, rdar://problem/94980084.
Remove the allowUnavailable parameter to lookupConformance(), and instead
explicitly check the result for hasUnavailableConformance() in the places
where we used to pass 'false'.
Also, narrow down this check in those places to the Sendable protocol
only, fixing a regression with Hashable conformance synthesis.
Fixes rdar://problem/94460143.
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.
If you have generic parameters <T, U> and requirements of the form:
- T : P
- T == ConcreteType<U>
- T.[P]U : SomeClass
- T.[P]U : SomeProto
And furthermore SomeClass does not conform to SomeProto, we can't leave
`T.[P]U : SomeClass` unsubstituted; we still have to replace `T` with
`ConcreteType<U>` to transform the latter two requirements into:
- U : SomeClass
- U : SomeProto
"Concrete contraction" is easily the hackiest part of the Requirement
Machine; I need to come up with a more principled solution for the
problem that it solves sooner or later.
Fixes rdar://problem/94150249.
We resolve protocol typealiases to DependentMemberTypes because the
Requirement Machine treats them as rewrite rules. However, it doesn't
do this for typealiases in protocol extensions.
Fixes rdar://problem/94150249.
Refusing to acknowledge unavailable conformances at this point in the
requirement machine doesn't allow us to make use of unavailable
conformances from unavailable contexts, something which code currently
depends on. Limit the new filtering behavior to `Sendable` conformances
where we need them, as a narrow fix for this regression. We'll revisit
the approach here later.
Fixes rdar://94154905.
When determining whether a superclass conforms to a particular protocol,
skip unavailable conformances. This way, we don't minimize away a
constraint that might only apply to subclasses of the specified
superclass.
Fixes rdar://91853658.
We infer requirements from types appearing in parameter and result types,
like this:
func foo<T>(_: Set<T>) // 'T : Hashable' inferred from 'Set<T>'
Normally we muffle the warning if the requirement is re-stated redundantly:
func foo<T>(_: Set<T>) where T : Hashable // no warning
However, in some cases we failed to do this if the requirement was inferred
from a type appearing in a 'where' clause, like this:
struct G<A, B> {}
extension G where B : Hashable, A == Set<B> {}
This is because in this case the redundancy was detected by
RewriteSystem::addRule() returning false.
The simplest fix here is to change InferredGenericSignatureRequest
to re-order requirements so that inferred requirements appear last.
This way, if any are redundant, we won't diagnose them since it is
the inferred requirement that is redundant and not the user-written
one.
Fixes rdar://problem/92092635.
Clean up the different cases by passing a 'Position' enum to
substTypeParameter().
Also generalize it to work with arbitrary type parameters instead
of generic parameters only, but leave this code path disabled
for now.
The GenericSignatureBuilder did not actually allow this, but it's conflict
detection was imperfect so it did not flag the example in the radar;
variations on this code were rejected by the GenericSignatureBuilder.
Since the Requirement Machine finds all conflicts correctly, relax the
logic here to make this example work.
Fixes rdar://problem/91637621.
warning.
These diagnostics are stricter in the RequirementMachine than in the GSB,
and there's code that relies on the more relaxed diagnostics in the source
compatibility suite. Downgrade these diagnostics to a warning using
warnUntilSwiftVersion(6).
Don't set allowMissing to true when checking conformance of a superclass requirement
to a protocol, since this prevents us from being able to express something like
'T : C, T : Sendable' to mean 'T can be any subclass of C which is also Sendable'.
Fixes rdar://problem/91530343.
A conformance requirement on a concrete type parameter is redundant if the
concrete type conforms to the protocol.
The replacement path for the conformance rule is based on a concrete
conformance rule introduced by the property map. Since the concrete
conformance rule is not associated with a requirement ID, this would
normally muffle the redundancy warning, because we don't want to
suggest removing a rule that depends on a non-redundant, non-explicit
rule.
However, concrete conformance rules don't actually appear in the
minimal signature, so skip them when computing the set of non-redundant,
non-explicit rules to ensure that the original conformance requirement
is still diagnosed as redundant.
