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

Quentin Colombet qcolombet at apple.com
Fri Nov 15 11:23:12 PST 2013

Hi Alp,

Thanks for sharing your thoughts.

On Nov 15, 2013, at 11:07 AM, 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.
I do not have a strong opinion on the naming and you made good points for calling that Diagnostic :).
I will wait for other feedbacks and rename that Diagnostic if nobody complains.
However, I think the naming of the method LLVMContext::report is fine.
What do you think?

> 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.
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131115/99a180b2/attachment.html>

More information about the llvm-commits mailing list