[llvm-dev] [cfe-dev] [RFC] improvements to LLVM diagnostic infrastructure

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 13 08:22:12 PDT 2017


Hi Sanne,

> On Mar 13, 2017, at 7:41 AM, Sanne Wouda via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hi all,
> 
> I'm working on improvements to diagnostics handling in LLVM, specifically for the benefit of the (integrated) assembler. The goal is to support options such as -Werror, -w, and -W<warning> for files assembled with clang and inline assembly. Clang already has support for these options but does not apply them to diagnostics originating from (inline) assembly.

I am not sure I get what you want to do.
That infrastructure already exists as far as I can tell. Look at BackendConsumer::DiagnosticHandlerImpl.

For historical reasons, it is possible the inline assembly stuff does not use it though.

Cheers,
-Quentin
> 
> I plan to add an LLVMDiagnosticsEngine class that takes responsibility for handling diagnostics options (superseding parts of SourceMgr and LLVMContext).

> The diagnostics themselves will be defined in TableGen (just like in clang).

> 
> Currently, diagnostics are passed through a SourceMgr to get location info and then passed on to a diagnostics handler for printing (if it exists). This is usually wrapped in Warning() and Error() functions.
> 
> For example in ARMAsmParser.cpp:
>  
>         Error(ImmLoc, "invalid immediate shift value");
> which eventually calls SourceMgr::PrintMessage.
> 
> This would change to (incrementally throughout the code-base) :
>        Diag(ImmLoc, err_arm_invalid_immediate_shift);
> and pass through LLVMDiagnosticsEngine to get the diagnostic message and severity (defined in TableGen, similar to Diagnostic*Kinds.td in clang).
> 
> Initially, LLVMDiagnosticsEngine will be a smaller, simpler version of clang's DiagnosticEngine. Over time, I would expect more features of clang's diagnostics to migrate to LLVM, where possible, to improve diagnostics for all the LLVM tools.
> 
>  
> I intend to implement the necessary infrastructure and convert a (small) number of diagnostics.  Further conversions can be done incrementally.
> 
> Any comments on this approach? Is this the right direction for diagnostics in LLVM? Suggestions more than welcome!
> 
> Thanks,
> Sanne
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170313/ac1d511b/attachment.html>


More information about the llvm-dev mailing list