Our tentative witness might have weird concrete DependentMemberTypes
in it. In that case, perform a more relaxed check that can succeed
as long as the witness is not completely invalid.
This problem was exposed by existing test cases starting to fail
once implicit Copyable requirements were introduced, because these
concrete DependentMemberTypes do not conform to protocols. This now
postpones the check until all witnesses have been fully substituted.
This also fixes a long-standing bug with superclass requirements on
associated types.
Fixes https://github.com/apple/swift/issues/48770,
https://github.com/apple/swift/issues/51772,
rdar://95729075.
This problem was introduced in 2017 by commit bbaa7f7163.
If a protocol requirement has multiple potential witnesses, and one
of those witnesses only introduces tautological type witness bindings,
we would be forced to choose among the remaining witnesses.
However, this did not account for the possibility that the
tautological witness is the correct choice; it's possible that we
will infer the same type witnesses via a different protocol
requirement.
resolveWitnessViaLookup() was only called from one place and didn't
need to force anything at all, and resolveSingleWitness() now only
forces the type witnesses actually referenced by the requirement.
An old crasher test case that was considered "fixed" when we started
to diagnose it now type checks correctly.
We don't want to throw out a witness if it has any mention of 'Self.Foo';
we must also check that 'Foo' is one of the associated types being
inferred. Otherwise, it may be a protocol type alias, in which case
we want to proceed with the witness.
This fixes a regression from a recent change, a576984e2f.
Fixes rdar://problem/120743365.
Associated type inference likes to wrap concrete types in
DependentMemberTypes. Calling mapTypeOutOfContext() on such
a type can crash. Open-code the transform instead.
Longer term, I want to clean up the invariants here and stop
mapping things in and out of different contexts randomly.
Consider this code:
protocol P {
associatedtype A
...
}
protocol Q: P {
associatedtype A = Int
...
}
struct S: Q {
...
}
If we check the [S: Q] conformance first, we get the right type witness
assignment, but if we check [S: P] first, conformance checking fails.
Instead of looking at an associated type declaration and any associated
types that it overrides, we now look through all associated types with the
same name among the protocols the adoptee conforms to. This allows us to
find the default assignment 'A = Int' from Q regardless of request
evaluation order.
Fixes rdar://problem/119052782.
When using an experimental feature that is not available
in production, a test needs to have `REQUIRES: asserts`
so that non-assert builds don't unexpectedly fail.
This PR refactors the ASTDumper to make it more structured, less mistake-prone, and more amenable to future changes. For example:
```cpp
// Before:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E) {
printCommon(E, "unresolved_dot_expr")
<< " field '" << E->getName() << "'";
PrintWithColorRAII(OS, ExprModifierColor)
<< " function_ref=" << getFunctionRefKindStr(E->getFunctionRefKind());
if (E->getBase()) {
OS << '\n';
printRec(E->getBase());
}
PrintWithColorRAII(OS, ParenthesisColor) << ')';
}
// After:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E, StringRef label) {
printCommon(E, "unresolved_dot_expr", label);
printFieldQuoted(E->getName(), "field");
printField(E->getFunctionRefKind(), "function_ref", ExprModifierColor);
if (E->getBase()) {
printRec(E->getBase());
}
printFoot();
}
```
* Values are printed through calls to base class methods, rather than direct access to the underlying `raw_ostream`.
* These methods tend to reduce the chances of bugs like missing/extra spaces or newlines, too much/too little indentation, etc.
* More values are quoted, and unprintable/non-ASCII characters in quoted values are escaped before printing.
* Infrastructure to label child nodes now exists.
* Some weird breaks from the normal "style", like `PatternBindingDecl`'s original and processed initializers, have been brought into line.
* Some types that previously used ad-hoc dumping functions, like conformances and substitution maps, are now structured similarly to the dumper classes.
* I've fixed the odd dumping bug along the way. For example, distributed actors were only marked `actor`, not `distributed actor`.
This PR doesn't change the overall style of AST dumps; they're still pseudo-S-expressions. But the logic that implements this style is now isolated into a relatively small base class, making it feasible to introduce e.g. JSON dumping in the future.
We want that (repeat each Element).[P]A == (repeat (each Element).[P]A),
where on the left is type witness projection from the tuple conformance,
and on the right is a tuple with a pack expansion.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
In https://github.com/apple/swift/pull/63898 conformance requirement
typechecking was relaxed to allow unavailable decls to witness conformance
requirements as long as the conforming nominal was also unavailable. However,
only nominals that were directly marked unavailable were accepted. Nominals
that are declared in unavailable scopes should also be allowed to have
unavailable wintesses.
Resolves rdar://107052715
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.
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.
- 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
If a rule is not a protocol typealias rule, and does not contain any unresolved
symbols, do not attempt to eliminate it via a protocol typealias rule.
This fixes a bunch of cases where the RequirementMachine was overly-eager to
remove rules.
rule has a non-explicit, non-redundant rule in its rewrite path.
This fixes bogus redundancy diagnostics in cases where the canonical form
of a redundant rule is not explicit in source, e.g.
protocol Swappable2 {
associatedtype A
associatedtype B
associatedtype Swapped : Swappable2
where Swapped.B == A,
Swapped.Swapped == Self
}
in the above case, the canonical rule for `Swapped.B == A` is the rule
[Swappable2:Swapped].[Swappable2:A] => [Swappable2:B], which is not
explicit.
