Previously, inverses were only accounted-for in inheritance clauses.
This batch of changes handles inverses appearing in other places, like:
- Protocol compositions
- `some ~Copyable`
- where clauses
with proper attribution of default requirements in their absence.
This implementation has the function execute a request to scan the
inheritance clause of non-protocol nominals for a `~Copyable`. For
protocols, we look in the requirement signature.
This isn't our final state, as the GenericEnvironment needs to be
queried in general to determine of a Type is noncopyable. So for now
checking for a `~Copyable` only makes sense for Decls.
The substituted witness type may depend on a tentative type witness
indirectly. In this case, we would incorrectly cache the result.
The outcome was that associated type inference would fail because
the first attempted witness would "lock in" a cached substituted
witness in some other specialized conformance.
We used to disallow pack expansions in generic argument lists of
protocols, but allow them for all other nominal types. However,
we only actually checked that the pack expansions match up if
the type itself was variadic.
Fix this by repurposing Context::ProtocolGenericArgument into
Context::ScalarGenericArgument, and using that when the type does
not have a parameter pack.
Context::GenericArgument is now Context::VariadicGenericArgument,
and we only use it if the type has a parameter pack, in which case
we use the PackMatcher, so any pack expansions in the wrong place
are caught there.
Fixes rdar://116716014 and https://github.com/apple/swift/issues/69088.
Applying generic arguments to a variadic generic type uses the
PackMatcher to build a mapping between generic parameters and
arguments.
The PackMatcher is symmetric, so there was an unexpected failure
mode that wasn't handled: if the variadic generic type had some
non-pack parameters, but the argument list was a single pack
expansion type, the match would succeed, grouping all of the
generic parameters into a single match.
This is non-sensical, so we need to explicitly check for this
case and diagnose it. This requires a new diagnostic, since
otherwise the general diagnostic we emit for variadic generic
type mismatches doesn't make sense, since it's complaining
about there being too few generic parameters.
Fixes rdar://116713961 / https://github.com/apple/swift/issues/69012.
We already had a separate TypeResolverContext::ProtocolGenericArgument that
did not allow PackExpansionTypes, but it was never used.
Fixes rdar://problem/115538574.
One of the request triggers added to `ConformanceLookupTable` in
https://github.com/apple/swift/pull/68384 can cause circular request
evaluation. Revert the request trigger since it doesn't appear to be necessary
for the test cases introduced in that PR.
Resolves rdar://115314044
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.
When we added same-shape requirements, we broke -analyze-requirement-machine,
which outputs some histograms. Add a regression test to make sure this code
path doesn't bitrot.
If the substitution terms of a concrete type symbol contain unresolved
name symbols, we have an invalid requirement that is dropped from the
minimized signature. In this case, the rewrite system used for minimization
cannot be installed as the official rewrite system for this generic
signature, because building a rewrite system from the signature will
produce a different result.
This might be the cause of the crash in rdar://114111159.
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.
The progress on variadic generics means we can now implement useful
witnesses in a tuple conformance. The feature remains very incomplete
though, today we crash in SILGen.
We want `T.A == U.B` to imply `shape(T) == shape(U)` if T (and thus U)
is a parameter pack.
To do this, we introduce some new rewrite rules:
1) For each associated type symbol `[P:A]`, a rule `([P:A].[shape] => [P:A])`.
2) For each non-pack generic parameter `τ_d_i`, a rule `τ_d_i.[shape] => [shape]`.
Now consider a rewrite rule `(τ_d_i.[P:A] => τ_D_I.[Q:B])`. The left-hand
side overlaps with the rule `([P:A].[shape] => [shape])` on the term
`τ_d_i.[P:A].[shape]`. Resolving the overlap gives us a new rule
t_d_i.[shape] => T_D_I.[shape]
If T is a term corresponding to some type parameter, we say that `T.[shape]` is
a shape term. If `T'.[shape]` is a reduced term, we say that T' is the reduced
shape of T.
Recall that shape requirements are represented as rules of the form:
τ_d_i.[shape] => τ_D_I.[shape]
Now, the rules of the first kind reduce our shape term `T.[shape]` to
`τ_d_i.[shape]`, where `τ_d_i` is the root generic parameter of T.
If `τ_d_i` is not a pack, a rule of the second kind reduces it to `[shape]`,
so the reduced shape of a non-pack parameter T is the empty term.
Otherwise, if `τ_d_i` is a pack, `τ_d_i.[shape]` might reduce to `τ_D_I.[shape]`
via a shape requirement. In this case, `τ_D_I` is the reduced shape of T.
Fixes rdar://problem/101813873.
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
Now that `InferredGenericSignatureRequest` creates
`StructuralRequirement`s from of the generic signature with valid source
locations, additional redundancy warnings are produced. Update tests
with the new warnings.
`InferredGenericSignatureRequest` creates `StructuralRequirement`s for
the requirements of the generic signature that is passed to it (if one
is).
Previously, it used invalid `SourceLoc`s for these requirements. The
result was that when errors that were emitted as a result of those
`StructuralRequirement`s (during concrete type contraction), they would
also have invalid `SourceLoc`s. The effect was that those errors were
ignored during `diagnoseRequirementErrors`.
Here, use the available loc for those requirements.
rdar://108963047
