[PATCH] Add warning capabilities in LLVM (backend part)

Sean Silva silvas at purdue.edu
Sat Nov 16 23:43:06 PST 2013


On Fri, Nov 15, 2013 at 2:07 PM, Alp Toker <alp at nuanti.com> wrote:

> Hi Quentin,
>
> This is neat!
>
> It could be nice to call it 'Diagnostic' rather than 'Report' in order to
> follow the existing convention in clang.
>
> Even if it works slightly differently than clang diags right now, it has
> pretty much the same purpose, is intended to feed into the clang diag
> system, and I think there's potential for an "eventual" unification of
> diagnostic facilities if this idea gets taken up in LLVM core.
>
> The benefit apart from familiar terminology would be that existing
> language binding wrappers, serializations and editor integration code could
> be lowered from clang and reused for standalone LLVM diagnostics and other
> language frontends some day.
>

Yeah, this has been an outstanding project for a while now. I wonder if we
could get a GSOC on it.

-- Sean Silva



>
> Alp.
>
>
> On 15/11/2013 18:17, Quentin Colombet wrote:
>
>> Hi dblaikie, echristo, rengolin, chandlerc,
>>
>> Hi,
>>
>> This patch implements the proposal discussed a few months ago (
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html)
>> regarding adding warning capabilities in LLVM.
>>
>> //// Overview ////
>>
>> The patch adds a new LLVMContext::report that can be used to communicate
>> to the front-end, if any, that something of interest happened.
>> The report contains the following information:
>> - The kind of the report: What this is this about.
>> - The severity of the report: How bad this is.
>> - The default message to print: What should be reported.
>> - A data field: Some meta information.
>>
>> The data field should be used to communicate all sort of data to the
>> front-end. Ultimately, this field should provide enough information to the
>> front-end so that it could build its own diagnostic if it does not want to
>> print the default message.
>> This means that both the back-end and the front-end should agree on the
>> structure of this field based on the pair kind/severity.
>> This feature is not stressed by this patch.
>>
>> This patch introduces a new ReportHandlerTy and a new ReportContext that
>> should be set by the front-end to be able to map these reports in its own
>> diagnostics system.
>>
>> //// Next Steps ////
>>
>> - Send the patch for clang (I have it on hold).
>> - Switch to this reporting for all warnings printing happening in the
>> backend.
>> - Switch the InlineAsmDiagHandler to the new reporting mechanism. This
>> involves a bit of work, especially regarding the meta data.
>>
>> Thanks for your reviews.
>>
>> Cheers,
>> Quentin
>>
>> PS: Sorry for the delay, it took my ages to get to this point in my
>> todolist.
>>
>> http://llvm-reviews.chandlerc.com/D2190
>>
>> Files:
>>    include/llvm/IR/LLVMContext.h
>>    lib/CodeGen/PrologEpilogInserter.cpp
>>    lib/IR/LLVMContext.cpp
>>    lib/IR/LLVMContextImpl.cpp
>>    lib/IR/LLVMContextImpl.h
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
> --
> http://www.nuanti.com
> the browser experts
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131117/ba3c3806/attachment.html>


More information about the llvm-commits mailing list