[LLVMdev] [RFC] Add warning capabilities in LLVM.

[Tobias Grosser]

On 07/26/2013 05:07 PM, Quentin Colombet wrote:
> On Jul 26, 2013, at 4:59 PM, Tobias Grosser <tobias at grosser.es> wrote:
>
>> On 07/26/2013 04:50 PM, Quentin Colombet wrote:
>>> Hi Tobias,
>>>
>>> On Jul 26, 2013, at 4:19 PM, Tobias Grosser <tobias at grosser.es> wrote:
>>>
>>>> On 07/25/2013 05:09 PM, Quentin Colombet wrote:
>>>>> Hi,
>>>>>
>>>>> I think we have a consensus on how we should report diagnostics now.
>>>>> For broader uses, the discussion is still open.
>>>>>
>>>>> To move forward on the diagnostic part, here is the plan:
>>>>> - Extend the current handler with a prototype like:
>>>>> void report(enum Kind, enum Classification, const char* msg)
>>>>> where
>>>>> - Kind is the kind of report: InlineAsm, StackSize, Other.
>>>>> - Classification is Error, Warning.
>>>>> - msg contains the fall back message to print in case the front-end do not know what to do with the report.
>>>>
>>>> Hello Quentin,
>>>>
>>>> could you explain how plugins would use your infrastructure?
>>> I am not familiar with how plug-ins work with LLVM, but let me try to sketch something.
>>>
>>> With the proposed infrastructure, LLVMContext will supply a callback to report events of special interest to the LLVM clients (clang, etc.).
>>> As long as the plugin has access to the LLVMContext, I do not see why it should not be able to report its own events.
>>> See the example below.
>>>
>>> Note that the proposed prototype changed recently to (see Chris’ email):
>>> void report(enum Kind, StringRef StringData, enum Classification, StringRef msg)
>>>
>>>> Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted?
>>> I think so.
>>> Typically, to report a warning, I would do from the plug-in:
>>> <get the LLVMContext>.report(Other, “Whatever”, Warning, “Weird stuff during plug-in analysis.”);
>>
>> That sounds good.
>>
>> The last question I have is, for what the 'Kind' parameter is used? Should plugins just use a generic kind 'Other' or would it make sense to support per plugin kinds. Specifically, I wonder how users could enable/disable certain warnings/reports.
> That is a good question!
>
> The basic idea is to add a value in the enum for each event we think it would be nice to have a special handling for (e.g., a new warning group in the front-end).
>
> The exact values of the Kind enum is something that needs to be discussed, but anyway, it can be extended in the future.

Alright. I believe to make it real nice for plugins, it would be great 
to eventually allow them to register new warning groups on demand. 
However, this is unrelated to the discussion. Having some infrastructure 
to output generic 'warnings' is a great start. People can then propose 
patches that make it even nicer for plugins.

Thanks for working on this,
Tobi