Display diagnostic error codes

[tboby]

Would it be possible for the diagnostic error code to be surfaced to the user in some way?

Diagnostics as defined in the LSP and vscode-api have a code field which is not easily visible to the user in vscode. Language servers/compilers often allow the suppression of specific diagnostics by passing a list of error codes to ignore. Currently, as far as I know, extensions have to intercept LSP diagnostics and hardbake the code into error message, or incorrectly use the source field.

E.g:


Both of these solutions are less than ideal, as they mean that the raw "Copy" data is incorrect, and inconsistent across extensions.

It seems odd that source, a field that is generally obvious from context, is displayed, but there is no proper support for the code field.

I'm not sure what the best way of actually displaying it would be, but a few things come to mind:

1. Add it to the hover (as suggested by @egamma in Problems/Diagnostics does not show "Code" #44017 )
2. Display it together with the source
3. Display it instead of the source, and move the source to the end of the row

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Diagnostics created by tasks aren't accessible to extensions (#47292)
• Diagnostics should support data field (#24682)

[tboby]

Neither of these issues are duplicate, although the second isn't far off, nice try!

[jrieken]

Yes, fair request. For the sake of completeness there is the hover, the f8-feature, and the error list.

It seems odd that source, a field that is generally obvious from context, is displayed,

The motivation for that is the presence of different validators, e.g. TypeScript for syntax/semantic checks and TSLint for linting.

Adding @sandy081 for the errors list and for more feedback

[sandy081]

I think the current format [${source}] ${message} (${line}, ${column}) is simple and clean. If we want to add code I would prefer to keep it before message, just like the example 1 in the description:

[${source}] ${code}: ${message} (${line}, ${column}) ??

[egamma]

How about showing it at the end. The message is the most important part of a diagnostic and it would be good when it comes first.

[${source}]: ${message} (${line}, ${column}) ${code} ??

[mattacosta]

I'm also guilty of (mis)using the source field for error codes.

While I also agree that the message is the most important part, I would also say that the code is equal to or greater in importance than the source because it is useful for things like error suppression comments or looking up documentation (such as googling "c# error 1234"), while the source is only useful if someone has multiple extensions with non-obvious diagnostics. Therefore option 3 would seem to be the best fit, but option 2 would also be acceptable if it's too much of a change.

[sean-mcmanus]

The C/C++ extension is adding error/warning codes so that users can disable particular errors/warnings like VS 2017 has so we'd highly like VS Code to add this. In the mean time, how do you recommend we expose the error codes to users? Our current plan is to add it to the end of the message until this is fixed. We're also adding "C/C++" as the source and many users have requested filtering based on that (I think there's another issue tracking that).

[sandy081]

How about showing error code at the end as @egamma mentioned

[jrieken]

Maybe not at the end-end but before the line/column info?

[tboby]

Oh, please prioritise it over message on narrow screens (like line numbers currently do)

Also, minor point, having line/column as far right causes things to line up nicely!

[sandy081]

Before line numbers

@tboby

[sandy081]

@egamma I see diagnostic code is being repeated in message part for TS Lint diagnostics. Is it possible to remove them from the message?

[egamma]

@sandy081 I´ve removed rendering of the code (the tslint ruleName) for tslint, but now the rule name no longer shows up in the hover. So the question is whether we should also show the code in the hover somehow.

[egamma]

@dbaeumer pls check whether you have the same issue of duplicate error code in eslint.

[cdeutsch]

Please bring back the name in the hover. If I need to disable a rule that's where I get the name from.

Now I'm stuck googling the error message or linting the whole project from the command line to get the name 🤦‍♂️

[dbaeumer]

@egamma I do.

@sandy081 the recommendation is to remove it right and we will add the code to the hover automatically as well.

[sandy081]

Yes

[dbaeumer]

Removed it from ESLint and published new version for ^1.28

[drKnoxy]

Hey i'm the maintainer of eslint-disable, any tips on how to get at the rule id so that we can disable rules again?

[dbaeumer]

@drKnoxy you might want to have a look at microsoft/vscode-eslint#530 which adds the as quick fixes to the extension directly.

[charpeni]

Starting from vscode-eslint@1.6.1, the easiest way to get eslint's rule id is to open the Problems window.

cc @cdeutsch @drKnoxy