Jordan Rose 6bd7e5e5b4 Make sure protocol witness errors don't leave the conformance context ...

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.

2018-05-10 19:31:12 -07:00

5.1 KiB

Raw Permalink Blame History

View Raw