This check had two problems. First, it would assert upon encountering
a layout requirement, due to an unimplemented code path.
A more fundamental issue is that the logic wasn't fully sound, because
it would miss certain cases, for example:
protocol P {
associatedtype A
func run<B: Equatable>(_: B) where B == Self.A
}
Here, the reduced type of `Self.A` is `B`, and at first glance, the
requirement `B: Equatable` appears to be fine. However, this
is actually a new requirement on `Self`, and the protocol be rejected.
Now that we can change the reduction order by assigning weights to
generic parameters, this check can be implemented in a better way,
by building a new generic signature first, where all generic
parameters introduced by the protocol method, like 'B' above, are
assigned a non-zero weight.
With this reduction order, any type that is equivalent to
a member type of `Self` will have a reduced type rooted in `Self`,
at which point the previous syntactic check becomes sound.
Since this may cause us to reject code we accepted previously,
the type checker now performs the check once: first on the original
signature, which may miss certain cases, and then again on the new
signature built with the weighted reduction order.
If the first check fails, we diagnose an error. If the second
check fails, we only diagnose a warning.
However, this warning will become an error soon, and it really
can cause compiler crashes and miscompiles to have a malformed
protocol like this.
Fixes rdar://116938972.
'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.
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
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.
RequirementEnvironment wasn't prepared to handle a protocol
requirement with additional 'where' clause constraints but
no generic parameters.
Since such a requirement necessarily runs afoul of the existing
"protocol requirements cannot constrain Self" rule, it suffices
to ignore such requirements when matching witnesses and let
the declaration checker diagnose this situation later.
Fixes <rdar://problem/61876053>.
For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
When enumerating requirements, always use the archetype anchors to
express requirements. Unlike "representatives", which are simply there
to maintain the union-find data structure used to track equivalence
classes of potential archetypes, archetype anchors are the
ABI-stable canonical types within a fully-formed generic signature.
The test case churn comes from two places. First, while
representatives are *often* the same as the archetype anchors, they
aren't *always* the same. Where they differ, we'll see a change in
both the printed generic signature and, therefore, it's
mangling.
Additionally, requirement inference now takes much greater
care to make sure that the first types in the requirement follow
archetype anchor ordering, so actual conformance requirements occur in
the requirement list at the archetype anchor---not at the first type
that is equivalent to the anchor---which permits the simplification in
IRGen's emission of polymorphic arguments.
PR #5857 started rejecting generic requirements that adding
constraints directly to 'Self', which means the requirements would be
unsatisfiable by some models. At the time that commit was merged, we
had thought the compiler crashed on all instances of this problem.
It turns out that, with assertions disabled, these protocols would be
accepted and could be used, so downgrade the error to a 'deprecated'
warning in Swift 3 compatibility mode.
We had two egregious errors in our handling of superclass constraints:
* We were recording superclass constraints on non-representative
potential archetypes, which meant they would get ignored.
* When two equivalence classes got merged, we wouldn't add the
superclass constraint to the representative.
Drive-by fix noticed while addressing rdar://problem/29075927.
It is possible to have requirement environments in which substitution
of the conforming type for Self into the requirement's signature would
result in substituted same-type requirements that no longer involve
type parameters. This triggered an assertion in the construction of
the requiremet environement; instead, just drop the requirement
because it is no longer interesting. Witness matching will simply fail
later one.
With this fix, it now because possible to add generic requirements to
a protocol that were unsatisfiable for certain models. For example,
the following protocol:
protocol P {
associatedtype A
associatedtype B
func f<T: P>(_: T) where T.A == Self.A, T.A == Self.B
}
can only be satisfied by conforming types for which Self.A ==
Self.B. SE-0142 will introduce a proper way to add such requirements
onto associated types. This commit makes any such attempt to add
requirements onto "Self" (or its associated types) ill-formed, so we
will reject the protocol P above with a diagnostic such as:
error: instance method requirement 'f' cannot add constraint
'Self.A == Self.B' on 'Self'
Fixes rdar://problem/29075927.
