Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
The attribute makes the declaration unavailable from the perspective of clients
of the module's public interface and was creating a loophole that admitted
inappropriate unavailability.
A protocol conformance witness must be as available as its requirement. In
Swift 6.1 and earlier, the conformance checker failed to note that witnesses in
unavailable extensions are unavailable. That bug was fixed by a previous
change, but there was no test case covering it so the difference in behavior
was not acknowledged.
Related to rdar://143466010.
'type' and 'missingType' are contextual types in the generic environment
of the witness thunk. We cannot simply map them into the environment of
the conformance, because if the conforming type is a class, the witness
thunk has an extra generic parameter at depth=0, index=0 and all other
generic parameters are shifted down by one depth.
It should not be possible to mark an associated type declaration unavailable
since doing so does not have an effect on how a conformance interacts with its
associated types.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
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.
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.
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
