Reconsider `Diagnostic.actions` (`CodeAction` property) for quickfix

[eed3si9n]

Ref #581
Ref #887

Problem

Hi, I am a maintainer of Scala language-related tooling, for example its incremental compiler Zinc etc.
We are currently in the process of implementing actionable diagnostics, which allows the Scala compiler and build tools to expose code edit suggestions via Diagnostic. Likely this will proceed using the Diagnostic.data.actions field.

As far as I can tell, most languages interested in using Diagnostic.data are interested in passing along CodeAction quick fixes. So far:

• clang (done as Diagnostic.codeActions)
• Scala (in progress)
• Erlang
• Rust
• XML

Am I wrong to assume that not having this standardized means that the LSP clients need to implement the embedded CodeAction support one by one for each language?

Possible Solution

I think this is a clear signal that we should standardize list of CodeAction as Diagnostic.actions. Maybe it could be paired with WorkspaceEditClientCapabilities to opt-into or out of having actions attached.

Notes

The primary reason "quick fix" did not happen previously seems to be based on the assumption that that computing the code suggestion would be expensive. Some code suggestions might be, but:

1. There are many other cheap code fixes, often already suggested via deprecation warning messages. See for example Implement quickfixes, aka actionable diagnostics (via CodeAction) scala/scala#10406.
2. There are also some class of warnings that only compiler can accurately emit because it has the precise knowledge that is often expensive for external linters to re-emulate. In Scala community, there are syntactic Scalafix and semantic Scalafix, and the latter can be very slow. An example of this is unused import statement. Another example is organizing import statements, because import in one line can affect the imports in latter lines.

[hokein]

+1, clangd already supports this (as an extension).

[michaelpj]

Isn't this already computable by the client, since CodeActions have a diagnostics field that says which Diagnostics it resolves? So a client could ask for diagnostics and code actions, and then match them up by looking through the code actions. Less efficient, perhaps, but still possible.