Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This changes the minimized signature in a very narrow edge case.
If you have
class C : P {}
and also
protocol P : C {}
protocol P where Self : C {}
then <T where T : P, T : C> now becomes <T : P> both with spellings;
before, the first one gave <T : P> and the second <T : C>.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
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 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.
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.
Remove the allowUnavailable parameter to lookupConformance(), and instead
explicitly check the result for hasUnavailableConformance() in the places
where we used to pass 'false'.
Also, narrow down this check in those places to the Sendable protocol
only, fixing a regression with Hashable conformance synthesis.
Fixes rdar://problem/94460143.
If you have generic parameters <T, U> and requirements of the form:
- T : P
- T == ConcreteType<U>
- T.[P]U : SomeClass
- T.[P]U : SomeProto
And furthermore SomeClass does not conform to SomeProto, we can't leave
`T.[P]U : SomeClass` unsubstituted; we still have to replace `T` with
`ConcreteType<U>` to transform the latter two requirements into:
- U : SomeClass
- U : SomeProto
"Concrete contraction" is easily the hackiest part of the Requirement
Machine; I need to come up with a more principled solution for the
problem that it solves sooner or later.
Fixes rdar://problem/94150249.
Refusing to acknowledge unavailable conformances at this point in the
requirement machine doesn't allow us to make use of unavailable
conformances from unavailable contexts, something which code currently
depends on. Limit the new filtering behavior to `Sendable` conformances
where we need them, as a narrow fix for this regression. We'll revisit
the approach here later.
Fixes rdar://94154905.
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.
Clean up the different cases by passing a 'Position' enum to
substTypeParameter().
Also generalize it to work with arbitrary type parameters instead
of generic parameters only, but leave this code path disabled
for now.
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.
- Allow duplicate concrete type and superclass requirements on the
same generic parameter, as long as they're identical. This can
arise if requirement inference infers a requirement which the
user then explicitly re-states.
- If duplicate requirements are found that name different types, drop
only that generic parameter from consideration without giving up
entirely.
- If a generic parameter is subject to both a concrete type and a
superclass requirement, proceed with the concrete type requirement
since it is more specific instead of giving up.
Consider this example:
protocol P : C {}
class C : P {}
<T where T : P>
The GenericSignatureBuilder thinks the minimized signature is
<T where T : P>. The RequirementMachine would minimize it down to
<T where T : C>. The latter is more correct, since the conformance
here is concrete and no witness table needs to be passed in at
runtime, however for strict binary compatibility we need to produce
the same signature as the GenericSignatureBuilder.
Accomplish this by changing the minimal conformances algorithm to
detect "circular concrete conformance rules", which take the form
[P].[concrete: C : Q]
Where Q : P. These rules are given special handling. Ordinarily a
protocol conformance rule is eliminated before a concrete conformance
rule; however concrete conformances derived from circular
conformances are considered to be redundant from the get-go,
preventing protocol conformances that can be written in terms of
such concrete conformances from themselves becoming redundant.
Fixes rdar://problem/89633532.
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.
