[cfe-dev] How to assign a Custom Diagnostic IDs in Clang Tool

[Don Hinton via cfe-dev]

It mostly seems to be used on the fly.  Take a look at how it's used in
clang-tidy and see if that'll work for you.

On Thu, Feb 1, 2018 at 4:35 PM, Roman Popov <ripopov at gmail.com> wrote:

> Ouch.
> What I've found out is that getCustomDiagID takes reference to C-Style
> array as a parameter. Not a StringRef. So it's really inconvenient to use:
> I can't declare FormatStrings in one place, and generate IDs in another
> place.
>
> 2018-02-01 16:21 GMT-08:00 Roman Popov <ripopov at gmail.com>:
>
>> Tool is standalone.  But yes, map is what I ended up with.
>>
>> Approach with DIAG_UPPER_LIMIT turned out to be not nice in other way:
>> there is no way to specify ID and FormatString in same place. So code with
>> enum is not very readable.
>>
>> So the only approach that works well is to map your own IDs to getCustomDiagID
>> IDs.
>>
>> -Roman
>>
>> 2018-02-01 16:09 GMT-08:00 Don Hinton <hintonda at gmail.com>:
>>
>>> I failed to ask what sort of tool you were writing and assumed it was
>>> standalone and didn't include any other components that may also call
>>> DiagnosticEngine::getCustomDiagID().  If that's not the case, e.g.,
>>> plugins or clang-tidy checkers, then you shouldn't rely on your set of id's
>>> starting at clang::diag::DIAG_UPPER_LIMIT+1.
>>>
>>> However, if you map them to a string anyway, there's no need to create
>>> your own contiguous enum.
>>>
>>> On Thu, Feb 1, 2018 at 2:00 PM, Roman Popov <ripopov at gmail.com> wrote:
>>>
>>>> Thanks, this works for me!
>>>>
>>>> On Feb 1, 2018 1:58 PM, "Don Hinton" <hintonda at gmail.com> wrote:
>>>>
>>>>> Btw, you still need to call DiagnosticEngine::getCustomDiagID(), but
>>>>> you can use your new enum to access the new id.
>>>>>
>>>>>
>>>>> On Thu, Feb 1, 2018 at 1:52 PM, Don Hinton <hintonda at gmail.com> wrote:
>>>>>
>>>>>> Are you trying to put the actual numerical value in the
>>>>>> documentation?  That won't work since it's based on the enum value that
>>>>>> gets computed at compile time -- actually via tablegen -- and changes over
>>>>>> time as diagnostics are added/removed.
>>>>>>
>>>>>> Tooling may already do this, but if not, just create your own enum
>>>>>> that starts at the first available value, clang::diag::DIAG_UPPER_LIMIT,
>>>>>> and go from there.  Then you can publish and use those enum values, e.g.,
>>>>>> MyTool::Some_Diag.  Take a look at how new id numbers are generated and use
>>>>>> the same technique, e.g.:
>>>>>>
>>>>>>   https://clang.llvm.org/doxygen/DiagnosticIDs_8cpp_source.htm
>>>>>> l#l00291).
>>>>>>
>>>>>> If you need a string you can pass on the command line, you can create
>>>>>> your own mapping.
>>>>>>
>>>>>> hth...
>>>>>> don
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 1, 2018 at 1:12 PM, Roman Popov via cfe-dev <
>>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> Looks like DiagnosticEngine does not allow to be instantiated with
>>>>>>> User-supplied IDs.
>>>>>>> The problem is that DiagnosticIDs is not an interface to IDs
>>>>>>> database, but rather a final class not designed for inheritance.
>>>>>>>
>>>>>>> So I don't find a way how Clang diagnostic library can be reused by
>>>>>>> 3rd party tool.
>>>>>>>
>>>>>>> 2018-02-01 12:10 GMT-08:00 Roman Popov <ripopov at gmail.com>:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I want to create a fixed sets of IDs for error messages in Clang
>>>>>>>> tool. So I can put them into tool documentation.
>>>>>>>>
>>>>>>>> Is it possible to somehow assign a fixed ID for diagnostic?
>>>>>>>> DiagnosticEngine::getCustomDiagID() generates ID automatically, so
>>>>>>>> I have no control on IDs.
>>>>>>>>
>>>>>>>> Should I probably instantiate my own DiagnosticEngine instead of
>>>>>>>> using one from AstContext ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Roman
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180201/d078e316/attachment.html>