- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
This fixes a regression from the rule sharing implementation; I forgot
to handle the imported rules in builder.ImportedRules here.
This makes the usage of RuleBuilder in conditional requirement
inference look like the other usages of RuleBuilder, except
that the results are passed to RewriteSystem::addRules() instead
of RewriteSystem::initialize().
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
If a type parameter is subject to both a conformance requirement
and a concrete type requirement, the concrete type might conform
conditionally.
In this case, introduce new requirements to satisfy the conditional
conformance.
Since this can add new hitherto-unseen protocols to the rewrite
system, restrict this feature to top-level generic signatures, and
not protocol requirement signatures. Allowing this to occur in
protocol requirement signatures would change the connectivity of
the protocol dependency graph (and hence the connected components)
during completion, which would be a major complication in the
design. The GSB already enforces this restriction.
I changed the existing conditional_requirement_inference.swift test
to run with -requirement-machine-inferred-signatures=verify. Since
one of the test cases there triggers an unrelated bug in the
Requirement Machine, I split it off into a new file named
conditional_requirement_inference_2.swift which still runs with
the GSB. Once the bug is fixed I'll merge the files again.
For SIL substituted generic signature construction to work, we must
perform this step if either the conformance requirement or the
concrete type requirement is explicit. Previously, we only did it
if the concrete type requirement was explicit.
This is still somewhat unprincipled and I need to think about it
some more before porting it over to the requirement machine.
Fixes https://bugs.swift.org/browse/SR-15254 / rdar://problem/84827656.
I have a lot more known-failing GSB test cases, but the limiting factor
now is the GSB's minimization algorithm, which runs first before the
requirement machine gets to see anything. Replacing that with a new
algorithm based on the rewrite system is the next step here.
If we have a conformance requirement T : P, and a concrete type
requirement T == G<...>, and G _conditionally_ conforms to P,
we would infer the conditional requirements of G needed to
satisfy the conformance.
However, if the conformance requirement T : P was not explicit,
this would mean in practice that we would need to infer an
infinite number of conditional requirements, because there
might be an infinite number of types T for which T : P.
Previously we would infer these up to some limit, based on
how many levels of nested types the GSB had expanded.
Since this is untenable, let's instead change the rules so
that conditional requirement inference is only performed
when the concretizing requirement was explicit.
