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? Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted? Cheers, Tobias
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! Cheers, -Quentin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130726/59083494/attachment.html>
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. Tobias
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