A same-shape requirement 'length(T...) == length(U...)' becomes a rewrite
rule 'T.[shape] => U.[shape]'. Reduced shape rules will drop the [shape]
term from each side of the rule, and create a same-shape requirement
between the two type parameter packs.
This fixes an edge case where we start with the following requirements:
- U : P
- T : P
- T.[P]A == C
- T == G<T.[P]A>
- U.[P]A == T.[P]A
and end up with the following set of minimal rules (where the type
witness for [P]A in the conformance G<C> : P is C):
- U.[P] => U
- U.[P:A] => T.[P:A]
- T.[concrete: G<C>] => T
- T.[concrete: G<C> : P] => T
Since U.[P]A and T.[P]A are concrete, we split the abstract same-type
requirement into two requirements, and re-run minimization:
- U : P
- T.[P]A == C
- U.[P]A == C
- T == G<C>
The concrete conformance rule T.[concrete: G<C> : P] => T does not
correspond to a requirement, so it was simply dropped, and the above
rules violate post-contraction invariants; T.[P]A is not a valid
type parameter because there is no conformance requirement T : P in
the minimized signature.
We can fix this by re-running concrete contraction after splitting
concrete equivalence classes. After contraction, the above requirements
turn into
- U : P
- C == C
- U.[P]A == C
- T == G<C>
Which correctly minimizes to
- U : P
- U.[P]A == C
- T == G<C>
Both concrete contraction and concrete equivalence classes are hacks,
and we should think of a way to directly express the transformations
they perform with the rewrite system.
Fixes https://github.com/apple/swift/issues/61192.
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.
A requirement of the form T == G<T> is never valid, and T == G<T.A>
will leave behind a term T.[P:A] once the conformance T : P is
dropped in contraction. So just ignore recursive requirements
here, allowing them to be properly diagnosed later.
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'.
With the change to include `SmallVector.h` directly in `LLVM.h` rather
than forward declaring in the only case it matters (ie. Clang <= 5),
these fixes are no longer needed. Since defaulted version is preferred
when there's no better choice (which is presumably the case if that's
how they were originally added), use it instead. Some uses were instead
changed to add `llvm::` so remove that too.
RequirementSignatureRequest
=> TypeAliasRequirementsRequest
=> isConstrainedExtension()
=> GenericSignatureRequest
=> RequirementSignatureRequest
Instead, use getTrailingWhereClause() as an approximation of
isConstrainedExtension().
Fixes rdar://problem/97236936.
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.
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.
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.
- If P is declared to inherit from Q and Q has an associated type named U, then
isValidTypeInContext() returns true for a type 'T.U' where 'T' is a generic
parameter conforming to P, and 'U' is the unresolved DependentMemberType, and
the type 'T.U' will simplify to the term 'T.[P:U]'.
- However, if completion failed while building the rewrite system for P's
requirement signature, then the requirement signature for P won't have a
rule [P].[Q] => [P]. As a result, getTypeForTerm() will fail when given
'T.[P:U]', because the property map entry for 'T' will not contain a
conformance to Q.
Work around this by manually adding protocol inheritance rules when building
a signature from a protocol whose requirement signature failed to compute.
This was triggered by the test case I added in the previous commit to
test/Generics/non_confluent.swift.
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.
It's possible for the requirement machine to fail to pick up a source location for its computed errors to attach to when
1) The declaration has no where clause
2) Nor does it have a generic parameter list
This is possible because of the magic of desugaring opaque types in input position to generic parameters a la
func foo(_ : some P<T, U>)
Try to use the first valid user-written inference source to derive a location.
rdar://92105516
