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

Quentin Colombet qcolombet at apple.com
Fri Jul 26 16:50:10 PDT 2013

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.”);
For the explanation I quote Chris:
> The idea is that "StringData+Kind" can be used to format something nice in clang, but that "msg" fully covers it for clients that don't know the Kind enum.

Hope this helps!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130726/59083494/attachment.html>

More information about the llvm-dev mailing list