This is an archive of the discontinued LLVM Phabricator instance.

[clangd] add an extension field to LSP to transfer the diagnostic's category
ClosedPublic

Authored by arphaman on Aug 10 2018, 10:36 AM.

Diff Detail

Event Timeline

arphaman created this revision.Aug 10 2018, 10:36 AM
ilya-biryukov added inline comments.Aug 13 2018, 1:43 AM
clangd/Diagnostics.h
40

Maybe store the string name of the category directly here? This struct was never optimized for efficiency, but aims to be independent of clang, so that the clients might interpret it without calling any clang-specific code (we do reuse the Level enum, though, but that's merely for code reuse)

clangd/Protocol.h
549

Maybe add a brief example of category names here, i.e. "semantic issue", etc.?

arphaman updated this revision to Diff 160464.Aug 13 2018, 3:14 PM
arphaman marked 2 inline comments as done.

Address review comments.

ilya-biryukov accepted this revision.Aug 14 2018, 10:33 AM

LGTM. Let's watch out for possible breakages in any of the clients, though. I've checked VSCode and it seems to be fine with the added fields.

This revision is now accepted and ready to land.Aug 14 2018, 10:33 AM
This revision was automatically updated to reflect the committed changes.

LGTM. Let's watch out for possible breakages in any of the clients, though. I've checked VSCode and it seems to be fine with the added fields.

This isn't in the spec and broke the LSP client eglot (https://github.com/joaotavora/eglot/pull/81). Why don't you put this in the "source" field, or concat it to the "message" field. Who can even use this information if it's not in the spec? Are clients supposed to code against every LSP server's whim?

LGTM. Let's watch out for possible breakages in any of the clients, though. I've checked VSCode and it seems to be fine with the added fields.

This isn't in the spec and broke the LSP client eglot (https://github.com/joaotavora/eglot/pull/81). Why don't you put this in the "source" field, or concat it to the "message" field. Who can even use this information if it's not in the spec? Are clients supposed to code against every LSP server's whim?

Thanks for the feedback. I'll make a patch that turns this off by default so that clients can opt-in into it.

LGTM. Let's watch out for possible breakages in any of the clients, though. I've checked VSCode and it seems to be fine with the added fields.

This isn't in the spec and broke the LSP client eglot (https://github.com/joaotavora/eglot/pull/81). Why don't you put this in the "source" field, or concat it to the "message" field. Who can even use this information if it's not in the spec? Are clients supposed to code against every LSP server's whim?

Thanks for the feedback. I'll make a patch that turns this off by default so that clients can opt-in into it.

Thank you very much, and sorry if I came across a bit hostile. What is this category field good for?

LGTM. Let's watch out for possible breakages in any of the clients, though. I've checked VSCode and it seems to be fine with the added fields.

This isn't in the spec and broke the LSP client eglot (https://github.com/joaotavora/eglot/pull/81). Why don't you put this in the "source" field, or concat it to the "message" field. Who can even use this information if it's not in the spec? Are clients supposed to code against every LSP server's whim?

Thanks for the feedback. I'll make a patch that turns this off by default so that clients can opt-in into it.

Thank you very much, and sorry if I came across a bit hostile. What is this category field good for?

NP! Fixed in r340449.