Repository navigation
Add DiagnosticTag Type #500
Description
VS Code recently added a DiagnosticTag type for attaching additional metadata to a diagnostic. These tags can be used by editors to control the presentation of diagnostics. See microsoft/vscode#51104 for a discussion of this
Currently only one tag type has been added on the vs code side: DiagnosticTag.Unnecessary. This tag makes diagnostics for unused variables or unreachable bits of code. VS Code renders code marked with DiagnosticTag.Unnecessary as faded out.
DiagnosticTag only adds metadata to a diagnostic and should not break clients that do not support it. With DiagnosticTag.Unnecessary for example, clients that do not support tags will still receive standard diagnostics for unused variables and can render them as regular errors / warnings / suggestions
Activity
[-]Add DiagnosticTag[/-][+]Add DiagnosticTag Type[/+]dbaeumer commentedon Jun 20, 2018
This is more complicated for the LSP. Since the LSP is implemented for different clients simply adding this without thinking about how it will be implemented on other clients is not what we should do. We at least do need flag this as a client capability. BTW: this is why I was not a big fan of adding this that way.
dbaeumer commentedon Jun 20, 2018
Another thing we need to consider is that Diagnostics flow in both ways. So even if a client doesn't handle a
DiagnosticTagwe need to spec that the client tries to preserve the information when a diagnostic object is send from the client to the server in a code action request.mjbvz commentedon Jun 20, 2018
Clients that do not support
DiagnosticTagshould still be able to consume the diagnostics, they just will miss out on the special rendering of those tags. For example, TS sends all unused variable as suggestion level diagnostics. A client that does not know aboutDiagnosticTagwill render them as normal inline suggestionsdbaeumer commentedon Jun 21, 2018
I agree, but the problem I have in the LSP are objects that flow in both ways and the fact that the LSP tries to work in a backwards compatible way and for different client implementation. So in general that means:
expensivevalues which the client drops anyways.This is all not an issue with the VS Code API since we have strict versioning which due to the loose Eco system of LSP we tried to avoid (btw debug does the same there with its protocol). So whenever we add
languageAPI to VS Code I try to do that in a way that makes it not too hard to support in LSP.rcjsuen commentedon Apr 9, 2019
Looks like this got added into
vscode-languageserver-node.See microsoft/vscode-languageserver-node#477.
KamasamaK commentedon Jul 29, 2019
Pending PR is #645
dbaeumer commentedon Aug 12, 2019
Yes, but only in a next version so far.
dbaeumer commentedon Sep 20, 2019
Updated spec on dbaeumer/3.15 branch.