[LLVMdev] [RFC] Add warning capabilities in LLVM.
qcolombet at apple.com
Fri Jul 26 16:50:10 PDT 2013
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:
>> 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)
>> - 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...
More information about the llvm-dev