LSP's diagnostic's 'code' and Clang's diagnostic category

Hi,

I noticed that Clangd doesn’t currently use LSP’s ‘code’ field in the Diagnostic structure when publishing the diagnostics. I would like to use it to send the name of the diagnostic’s category to the client (e.g. “Semantic Issue” / “Parsing Issue”). Would it make sense to use the ‘code’ field for this, and would it make sense to turn it on by default? Are there any other plans to use it for something else instead?

Cheers,
Alex

Good question! I’m not aware of any discussion around this.

Using the diagnostic category seems a little course-grained, I think the most natural fit would be the diagnostic name itself like “warn_asm_qualifier_ignored”.

If you want the category too, any of these seem ok to me:

  • code = category/name, e.g. “Parse/warn_asm_qualifier_ignored”
  • add “category” attribute to diagnostic as LSP extension (I’d have no problem with keeping this always on)
  • keep a lookup table in the client (if consuming the tabledef files and maintaining version lock works for you)

What do you think?

Good question! I'm not aware of any discussion around this.

Using the diagnostic category seems a little course-grained, I think the
most natural fit would be the diagnostic name itself like
"warn_asm_qualifier_ignored".

If you want the category too, any of these seem ok to me:
- code = category/name, e.g. "Parse/warn_asm_qualifier_ignored"

Just to make sure I understand this correctly: for warnings the code would
be something like "Parse Issue/warn_asm_qualifier_ignored", and for errors
we would just send "Semantic Issue/"?
That should work for us.

- add "category" attribute to diagnostic as LSP extension (I'd have no
problem with keeping this always on)
- keep a lookup table in the client (if consuming the tabledef files and
maintaining version lock works for you)

Not really, we want to send the category name from the server.

Not quite: I think error diagnostics also have names as well as categories. E.g. “Semantic Issue/err_expr_not_ice” (first error from DiagnosticSemaKinds.td).

Makes sense, one of the other options then.

(An LSP extension attribute seems marginally cleaner than parsing it out of the code, but I’m happy with either)

Hi Alex, Sam,

My guess would be that the original intention of the ‘code’ was to expose the errors codes from various Microsoft’s compiler, e.g.

If the guess is correct, sending a diagnostic name (e.g. ‘err_expr_not_ice’) seems to be aligned with the original intention, but sending the generalized category is not.
With that in mind, I would be on the side of adding a ‘category’ field as an extension, rather than trying to reuse the ‘code’ field.

Hi Alex, Sam,

My guess would be that the original intention of the ‘code’ was to expose the errors codes from various Microsoft’s compiler, e.g.

If the guess is correct, sending a diagnostic name (e.g. ‘err_expr_not_ice’) seems to be aligned with the original intention, but sending the generalized category is not.
With that in mind, I would be on the side of adding a ‘category’ field as an extension, rather than trying to reuse the ‘code’ field.

That sounds sensible. I’ll work on adding an extension field instead then.
Cheers,
Alex