a warning.
Previous compiler versions allowed this, so we should stage the change in as
a warning. This was already a warning across modules, so this change only impacts
redundant conformances to marker protocols within a module. This code also isn't
particularly harmful, because marker protocols don't have requirements, so there
isn't the same risk of unexpected behavior as other redundant conformances.
If a protocol provides a deprecated default implementation for a requirement
that is not deprecated, the compiler should emit a warning so the programmer
can provide an explicit implementation of the requirement. This is helpful
for staging in new protocol requirements that should be implemented in
conforming types.
Obsoleting `AnyActor` in Swift 6 blocks the Concurrency library itself
from migrating to Swift 6, because `Actor` and `DistributedActor` have to
preserve their refinement of `AnyActor` to avoid breaking code currently
using the marker protocol. There's no way to move protocol refinement into
an extension so that the use-site declaration can be obsoleted, so we're
stuck with just the deprecation of `AnyActor`.
I'm not really convinced that this shouldn't be done by introducing a new
kind of constraint rather than hacking in what are essentially conversions
as "bind" constraints, but this is the most direct path for now.
Fixes rdar://125394096
I forgot that a protocol composition (C & P) can satisfy a superclass
requirement [T : D] in one narrow case implemented in
TypeBase::isExactSuperclassOf():
- D is a superclass of C
- P is an @objc protocol
- C is declared in Objective-C
This case was ruled out here because the code assumed the type witness
had to be a concrete class or archetype to satisfy a superclass
requirement.
Fixes rdar://problem/123543200.
This addresses a performance regression from 83cb420ee4.
In the old associated type inference implementation, we used to
fold valid solutions by comparing type witnesses, but this was
not correct as described in the commit message there.
After my fix we started to record more valid solutions from the
same search space, and this caused a performance regression
because we were already doing exponential work.
However in the program in question, each possible choice of witness
for a requirement would introduce the same bindings, so there was
nothing to gain from trying them all.
Since ranking only compares pairs of witnesses for the same
requirement, we can optimize this problem another way: by folding
identical terms in a disjunction, but only if *all* terms are
identical, which avoids the correctness issue in the old search
strategy.
Fixes rdar://problem/123334433.
If we have an abstract witness, we don't attempt a generic parameter
binding at all. But if simplifying the abstract witness failed, we
should still attempt it.
This would be cleaner as a disjunction in the solver but I want
to change behavior as little as possible, so this adds a new fallback
that we run when all else fails.
Fixes rdar://problem/123345520.
We used to do attempt things in this order:
- abstract witnesses, defaults, generic parameters
I tried this but it broke things:
- generic parameters, abstract witnesses, defaults
Hoping this sticks:
- abstract witnesses, generic parameters, defaults
Fixes rdar://123262178.
Requirement lowering only expects that it won't see two requirements
of the same kind (except for conformance requirements). So only mark
those as conflicting.
This addresses a crash-on-invalid and improves diagnostics for
move-only generics, because a conflict won't drop the copyability
of a generic parameter and expose a move-only-naive user to
confusing error messages.
Fixes#61031.
Fixes#63997.
Fixes rdar://problem/111991454.
Instead of computing the reduced type of the witness upfront and
then checking for canonical equality in type matching, check for
reduced equality in type matching.
This restores the old behavior and prevents us from considering too
many protocol extension witnesses, while fixing the request cycle
that motivated the change to instead match against the reduced type
of the witness.
Fixes rdar://problem/122589094, rdar://problem/122596633.
This effectively reverts d0bd026077, so
we now look for abstract type witnesses before generic parameters.
In particular, this means we again prefer the default type witness
over a generic parameter if nothing else forces it to be a generic
parameter:
protocol P { associatedtype A = Int }
struct S<T>: P {}
// S.T is always Int
Fixing this properly requires modeling generic parameter bindings as
disjunctions, which is a more disruptive change than I want to take
for now.
Fixes rdar://problem/122587432.
If a protocol fixes an associated type of another protocol via a
concrete same-type requirement, we should make use of this fact
immediately when building the associated type inference constraint
system.
Previously we only introduced fixed type bindings at the end, and
only in the 'abstract type witness' inference path, which we
reach if a type witness cannot be resolved by looking at value
witnesses alone.
This meant that associated type inference would find valid or
ambiguous solutions which would then be contradicted by the
ensureRequirementsAreSatisfied() check.
Longer term, what I want to do is actually build the type witness
system upfront, and also teach the constraint solver here about
merging equivalence classes, so that we can split them again when
backtracking. This will combine the best of both approaches.
Fixes rdar://problem/122586992.
A minimal Sequence conformance only needs to define an Iterator type,
with the Element type witness inferred from the Element of the iterator.
This trick didn't always work if the conforming type conformed to other
protocols with declared same-type requirements involving Self.Element.
Refine the heuristic introduced in 23599b667b
to prefer abstract type witnesses in the current protocol, even if there
is a shorter one in another protocol.
Fixes rdar://problem/122574126, rdar://problem/122588328.
If P is our protocol and it has an associated type A, we can't just
fold any dependent member type T.[Q]A to T.[P]A; this only makes
sense if T conforms to P.
Fixes rdar://problem/122587920.
If we have an inner generic parameter of the requirement on the LHS,
it can't match anything other than an inner generic parameter on the RHS.
If we have the protocol Self type on the LHS, it can only match
something with the same nominal on the RHS. This should be an exact
match but ideally we would also recursively solve dependnet member
types, etc. Skip this all for now.
If matching a candidate value witness against a protocol requirement produced
non-viable bindings, then don't consider the witness in the solver; it can
never lead to a valid solution.
We folded away viable solutions with identical type witnesses;
the first one "wins". However, solutions also store the value
witnesses from which those type witnesses were derived, and
this determines their ranking.
Suppose we have three solutions S_1, S_2, S_3 ranked as follows:
S_1 < S_2 < S_3
If S_1 and S_3 have identical type witnesses, then one of two
things would happen:
Scenario A:
- we find S_1, and record it.
- we find S_2, and record it.
- we find S_3; it's identical to S_1, so we drop it.
Scenario B:
- we find S_3, and record it.
- we find S_2, and record it.
- we find S_1; it's identical to S_3, so we drop it.
Now, we the best solution Scenario A is S_1, and the best
solution in Scenario B is S_3.
To fix this and ensure we always end up with S_1, remove this
folding of solutions, except for invalid solutions where it
doesn't matter.
To avoid recording too many viable solutions, instead prune the
solution list every time we add a new solution. This maintains the
invariant that no solution is clearly worse than the others; when
we get to the end, we just check if we have exactly one solution,
in which case we know it's the best one.
Fixes rdar://problem/122586685.
