<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 8 Aug 2018 at 04:35, Ilya Biryukov <<a href="mailto:ibiryukov@google.com">ibiryukov@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Alex, Sam,<div><br></div><div>My guess would be that the original intention of the 'code' was to expose the errors codes from various Microsoft's compiler, e.g.</div><div>- One of C++ error codes from MSVC: <a href="https://docs.microsoft.com/en-gb/cpp/error-messages/compiler-errors-1/compiler-error-c2059" target="_blank">https://docs.microsoft.com/en-gb/cpp/error-messages/compiler-errors-1/compiler-error-c2059</a><br></div><div>- One of C# error codes: <a href="https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs1513" target="_blank">https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs1513</a></div><div><br></div><div>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.</div><div>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.</div></div></blockquote><div><br></div><div>That sounds sensible. I'll work on adding an extension field instead then.</div><div>Cheers,</div><div>Alex</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 8, 2018 at 3:55 AM Sam McCall via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 8, 2018, 03:46 Alex L <<a href="mailto:arphaman@gmail.com" target="_blank">arphaman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 August 2018 at 18:29, Sam McCall <span dir="ltr"><<a href="mailto:sammccall@google.com" rel="noreferrer" target="_blank">sammccall@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Good question! I'm not aware of any discussion around this.</div><div dir="auto"><br></div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto">If you want the category too, any of these seem ok to me:</div><div dir="auto">- code = category/name, e.g. "Parse/<span style="font-family:sans-serif">warn_asm_qualifier_ignored"</span></div></div></blockquote><div><br></div><div>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/"?</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That should work for us.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><span style="font-family:sans-serif">- add "category" attribute to diagnostic as LSP extension (I'd have no problem with keeping this always on)</span></div><div dir="auto"><span style="font-family:sans-serif">- keep a lookup table in the client (if consuming the tabledef files and maintaining version lock works for you)</span></div></div></blockquote><div><br></div><div>Not really, we want to send the category name from the server.</div></div></div></div></blockquote></div></div><div dir="auto">Makes sense, one of the other options then.</div><div dir="auto"><br></div><div dir="auto">(An LSP extension attribute seems marginally cleaner than parsing it out of the code, but I'm happy with either)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">What do you think?</span></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div><div class="m_-6562113081402092333m_7997922359083344058m_8945669413108884276h5"><div dir="ltr">On Wed, Aug 8, 2018, 01:50 Alex L via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" rel="noreferrer" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-6562113081402092333m_7997922359083344058m_8945669413108884276h5"><div dir="ltr">Hi,<div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Alex</div></div></div></div>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div></div></div>
</blockquote></div><br></div></div>
</blockquote></div></div></div>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-6562113081402092333gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div>
</blockquote></div></div>