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
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
The protocol conformance checker tries to delay the emission of
diagnostics related to the failure of a type to conform to a protocol
until the source file that contains the conformance is encountered, to
provide redundant diagnostics. However, if a file produced only such
delayed diagnostics, such that all diagnostics were suppressed,
invalid ASTs could slip through to later stages in the pipeline where
they would cause verification errors and crashes. This happens
generally with whole-module-optimization builds, where we are re-using
an ASTContext when typing multiple source files.
This is a narrow-ish fix to stop dropping diagnostics from one source
file to the next in whole-module-optimization builds. Part of
rdar://problem/29689007.