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.
When comparing a requirement to a witness for @objc protocols, strip
optionality out of the types and keep track of the optionality
differences separately. When we have actually matched a witness,
diagnose any unsafe (via an error) or ill-advised (via a warning)
differences, providing Fix-Its to update the optionality.
This change addresses a usable problem introduced by the fix to
rdar://problem/18383574: witnesses for optional requirements of @objc
protocols could previously have completely wrong optionality, and we
would "allow" it by not actually matching the witness to the
requirement. Then it would happen to work at runtime because it's
@objc. Now, we match those witnesses and diagnose issues, with Fix-Its
to clean up the user's code.
Addresses rdar://problem/19656106.
Swift SVN r24939
