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
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.
Every protocol gets an 'identity conformance' rule [P].[P] => [P].
A trivially-stated circularity is always redundant because of this
rule, and we diagnose circular inheritance elsewhere as a hard
error, so just add a special case to skip adding such a rule here
to avoid the useless warning on top of the existing error.
We want to allow this for all conformance requirements written in protocols
or the `where` clause of protocol extensions.
Fixes rdar://problem/91304291.
When computing an overlap between a property-like rule (T.[p] => T for some
property symbol [p]) and another rule, try harder to ensure that the new
rule is a property-like rule.
In a conformance-valid rewrite system, all rules that are not LHS- or RHS-
simplified will eventually either be property-like or same-type rules, but
we need to maintain this invariant for that rules that become simplified
as well, to ensure that rewrite loops have a certain structure that is
important for the minimal conformances algorithm.
I don't quite understand why to be honest, but I'm close to figuring it
out.
Fixes rdar://problem/91232987.
computing a concrete same-type or superclass for conflict diagnostics.
Otherwise, diagnostics will show fresh type parameters when the concrete
type is generic.
