All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
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.
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
An extension might have an extended nominal, even if the extended type
is an error type. This can happen if, for example, the type lookup was
ambiguous, because the declaration lookup more eagerly disambiguates.
This is fine, because even if we bind the extension to a nominal it's
okay to diagnose an error later. However, we do have to deal with this
case here by checking for an error type.
A better solution would be to ensure the extended type is always set
to something, even if we diagnosed an error while resolving it, because
we can always use the declared type of the extended nominal instead.
However when I tried that I ran into more problems, and I don't feel
like shaving this yak right now.