[PATCH] Store warning option for custom diagnostic messages.

[Alexander Kornienko]

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/20140203/e832f7c6/attachment.html>