[PATCH] Store warning option for custom diagnostic messages.

[Alexander Kornienko]

Alp, ping.


On Mon, Feb 3, 2014 at 8:36 PM, Alexander Kornienko <alexfh at google.com>wrote:

> Alp, ping.
>
>
>
> On Thu, Jan 30, 2014 at 11:58 PM, Alexander Kornienko <alexfh at google.com>wrote:
>
>> On Thu, Jan 30, 2014 at 8:05 PM, Alp Toker <alp at nuanti.com> wrote:
>>
>>>
>>> On 30/01/2014 18:29, Jordan Rose wrote:
>>>
>>>>    Alp was trying to move away from getCustomDiagID, so you should
>>>> probably talk to him about this.
>>>>
>>>
>>> Thanks for pinging Jordan, that's right.
>>>
>>> Alex, can you provide an example of how you intend to use this facility,
>>> say a patch making use of it with a test case to get the full picture?
>>>
>>
>> One example of usage is in this patch:
>> http://llvm-reviews.chandlerc.com/D2661 (the test is in
>> clang/tools/extra/test/clang-tidy/basic.cpp). Another usage may appear in
>> the static analyzer, if we go forward with the checker name forwarding. The
>> idea is, that both clang-tidy and the static analyzer have a concept of
>> named checks (or checkers), that can be enabled or disabled from the
>> command line. It is similar to built-in diagnostics in clang, except for
>> the difference in the option syntax (for clang-tidy it's -checks=<regex>
>> and -disable-checks=<regex> instead of -W[no-]diagnostic-name). It seems to
>> be reasonable to use something similar to getWarningOptionForDiag to pass
>> check names through the DiagnosticEngine. Currently this is not available
>> for custom diagnostics.
>>
>> Both clang-tidy and the static analyzer use custom diagnostics, as they
>> are built optionally, and we can't statically generate diagnostics and make
>> clang pick them up in the way built-in diagnostics are handled.
>> Furthermore, we have plans for clang-tidy to support custom out-of-tree
>> check modules, which would make this even more complicated. So we have to
>> use custom diagnostics, and I propose adding making some features of
>> built-in diagnostics available for custom diagnostics (for now,
>> getWarningOptionForDiag).
>>
>>
>>> There's a place for getCustomDiagID() so we wont phase it away entirely
>>> but I've got a feeling there might be a cleaner solution in this instance.
>>
>>
>> If you have a better idea, I'd be happy to discuss it.
>>
>>
>>>
>>> (As for the patch, there are a couple of nits. I'll provide an inline
>>> review if we do want to go with it.)
>>>
>>> Alp.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140205/8f4fe807/attachment.html>