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.
If we reference an invalid type witness (e.g., a type witness for
which we ended up setting an error type because it couldn't be
satisfied), but the diagnostic that complains about the broken type
witness won't be diagnosed in this source file, complain that we're
referencing a bogus diagnostic. Since these diagnostics can be noisy
for broken code, only do so if no other diagnostics have been emitted
thus far.
Note that we need to produce *a* diagnostic here, otherwise we might
continue on to later stages of the compiler with our invalid ASTs.
Fixes rdar://problem/29689007.
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.
