[clangd-dev] LSP's diagnostic's 'code' and Clang's diagnostic category

[Ilya Biryukov via clangd-dev]

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.
- One of C++ error codes from MSVC:
https://docs.microsoft.com/en-gb/cpp/error-messages/compiler-errors-1/compiler-error-c2059
- One of C# error codes:
https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs1513

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.

On Wed, Aug 8, 2018 at 3:55 AM Sam McCall via clangd-dev <
clangd-dev at lists.llvm.org> wrote:

>
>
> On Wed, Aug 8, 2018, 03:46 Alex L <arphaman at gmail.com> wrote:
>
>>
>>
>> On 7 August 2018 at 18:29, Sam McCall <sammccall at google.com> wrote:
>>
>>> 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/"?
>>
>
> 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).
>
> 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.
>>
> 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)
>
>
>>
>>>
>>> What do you think?
>>>
>>> On Wed, Aug 8, 2018, 01:50 Alex L via clangd-dev <
>>> clangd-dev at lists.llvm.org> wrote:
>>>
>>>> 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
>>>> _______________________________________________
>>>> clangd-dev mailing list
>>>> clangd-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>>>>
>>>
>> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>


-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20180808/43a3c374/attachment.html>