`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
getInheritedProtocols() skips type resolution and directly resolves
TypeReprs to TypeDecls.
On the other hand, when building a protocol requirement signature,
we use type resolution to resolve inheritance clause entries so
that we can properly support parameterized protocol types, and
protocol compositions that contain classes.
Since a TypeRepr with an invalid sub-component resolves to an
ErrorType, this meant that in invalid code, the first list of
protocols might contain protocols that don't appear in the second.
This broke rewrite system invariants. Fix this by checking if
type resolution failed when building the requirement signature of
a protocol, and if so, also look at getInheritedProtocols().
Fixes https://github.com/apple/swift/issues/61020.
Previously, only the pattern type was added as a requirement inference source, but
the pack expansion type is necessary for inferring same-shape requirements for
packs that are expanded in parallel.
A same-shape requirement 'length(T...) == length(U...)' becomes a rewrite
rule 'T.[shape] => U.[shape]'. Reduced shape rules will drop the [shape]
term from each side of the rule, and create a same-shape requirement
between the two type parameter packs.
This fixes an edge case where we start with the following requirements:
- U : P
- T : P
- T.[P]A == C
- T == G<T.[P]A>
- U.[P]A == T.[P]A
and end up with the following set of minimal rules (where the type
witness for [P]A in the conformance G<C> : P is C):
- U.[P] => U
- U.[P:A] => T.[P:A]
- T.[concrete: G<C>] => T
- T.[concrete: G<C> : P] => T
Since U.[P]A and T.[P]A are concrete, we split the abstract same-type
requirement into two requirements, and re-run minimization:
- U : P
- T.[P]A == C
- U.[P]A == C
- T == G<C>
The concrete conformance rule T.[concrete: G<C> : P] => T does not
correspond to a requirement, so it was simply dropped, and the above
rules violate post-contraction invariants; T.[P]A is not a valid
type parameter because there is no conformance requirement T : P in
the minimized signature.
We can fix this by re-running concrete contraction after splitting
concrete equivalence classes. After contraction, the above requirements
turn into
- U : P
- C == C
- U.[P]A == C
- T == G<C>
Which correctly minimizes to
- U : P
- U.[P]A == C
- T == G<C>
Both concrete contraction and concrete equivalence classes are hacks,
and we should think of a way to directly express the transformations
they perform with the rewrite system.
Fixes https://github.com/apple/swift/issues/61192.
Note the test cases in abstract_type_witnesses used to pass but are now
rejected. This is fine, because doing anything more complicated used to
crash, and the GSB would crash or misbehave with these examples.
A requirement of the form T == G<T> is never valid, and T == G<T.A>
will leave behind a term T.[P:A] once the conformance T : P is
dropped in contraction. So just ignore recursive requirements
here, allowing them to be properly diagnosed later.
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
With the change to include `SmallVector.h` directly in `LLVM.h` rather
than forward declaring in the only case it matters (ie. Clang <= 5),
these fixes are no longer needed. Since defaulted version is preferred
when there's no better choice (which is presumably the case if that's
how they were originally added), use it instead. Some uses were instead
changed to add `llvm::` so remove that too.
