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.
initializing a RequirementMachine for a written protocol signature.
These generic parameters are used for re-sugaring when computing a
type from a term, so if the recorded 'Self' parameter is canonicalized,
it shows up in diagnostics as 'tau_0_0'.
A protocol typealias 'typealias T = X' introduces a same-type requirement
'Self.T == Self.X'. However the right hand side of the requirement was
wrapped in a sugared TypeAliasType.
This meant if the requirement surfaced in a redundancy diagnostic, it
would print as 'Self.T == Self.T'. It could also trigger a request cycle
via isInterestingTypealias() in DiagnosticEngine.cpp.
