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

Tobias Grosser tobias at grosser.es
Fri Jul 26 16:59:43 PDT 2013

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.


More information about the llvm-dev mailing list