
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jul 26, 2013, at 4:59 PM, Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 07/26/2013 04:50 PM, Quentin Colombet wrote:<br><blockquote type="cite">Hi Tobias,<br><br>On Jul 26, 2013, at 4:19 PM, Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> wrote:<br><br><blockquote type="cite">On 07/25/2013 05:09 PM, Quentin Colombet wrote:<br><blockquote type="cite">Hi,<br><br>I think we have a consensus on how we should report diagnostics now.<br>For broader uses, the discussion is still open.<br><br>To move forward on the diagnostic part, here is the plan:<br>- Extend the current handler with a prototype like:<br>void report(enum Kind, enum Classification, const char* msg)<br>where<br>- Kind is the kind of report: InlineAsm, StackSize, Other.<br>- Classification is Error, Warning.<br>- msg contains the fall back message to print in case the front-end do not know what to do with the report.<br></blockquote><br>Hello Quentin,<br><br>could you explain how plugins would use your infrastructure?<br></blockquote>I am not familiar with how plug-ins work with LLVM, but let me try to sketch something.<br><br>With the proposed infrastructure, LLVMContext will supply a callback to report events of special interest to the LLVM clients (clang, etc.).<br>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.<br>See the example below.<br><br>Note that the proposed prototype changed recently to (see Chris’ email):<br>void report(enum Kind, StringRef StringData, enum Classification, StringRef msg)<br><br><blockquote type="cite">Would it be possible for a plugin to provide (limited) warnings/diagnostics without requiring clang/LLVM to be adapted?<br></blockquote>I think so.<br>Typically, to report a warning, I would do from the plug-in:<br><get the LLVMContext>.report(Other, “Whatever”, Warning, “Weird stuff during plug-in analysis.”);<br></blockquote><br>That sounds good.<br><br>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.<br></div></blockquote><div>That is a good question!</div><div><br></div><div>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).</div><div><br></div><div>The exact values of the Kind enum is something that needs to be discussed, but anyway, it can be extended in the future.</div><div><br></div><div>-Quentin</div></div></body></html>