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

Alex L via clangd-dev clangd-dev at lists.llvm.org
Wed Aug 8 10:02:04 PDT 2018


On Wed, 8 Aug 2018 at 04:35, Ilya Biryukov <ibiryukov at google.com> wrote:

> 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.
>

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


>
> 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/7e0a9079/attachment-0001.html>


More information about the clangd-dev mailing list