That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
The fix for <https://bugs.swift.org/browse/SR-617> introduced
a new kind of requirement environment where 'Self' remains a
generic parameter, but receives a class constraint, instead of
becoming fully concrete.
As before, we would form the synthetic signature by taking
the generic signature of the requirement, and substituting it
the new 'Self' type.
However, whereas previously the 'Self' type was always concrete
and any DependentMemberTypes in the requirement's signature
would become concrete type references, with a class-constrained
'Self' the DependentMemberTypes remain.
Apparently, the GSB cannot handle DependentMemberTypes where
the base is class-constrained.
Work around this by ensuring that we add a conformance constraint
for the 'Self' parameter to the protocol in question, which
allows the DependentMemberTypes to be correctly resolves once
the conformance is made concrete by a superclass constraint.
The FIXME comment being removed here references crashes which
no longer seem to reproduce, so I'm assuming some underlying
GSB issues got fixed and the FIXME is clearly no longer necessary.
However, I still consider this fix somewhat unsatisfying, because
it is not clear if there's some deeper flaw in how the GSB
models superclass constraints. It might resurface again in the
future.
Fixes <rdar://problem/39419121>, <https://bugs.swift.org/browse/SR-7428>.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
