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

[Hal Finkel via llvm-dev]

On 03/13/2017 01:04 PM, Sanne Wouda via llvm-dev wrote:
>
> Hi Quentin,
>
> Thank you for the pointer to BackendConsumer::DiagnosticsHandlerImpl. 
> I'll have to investigate if it would fulfill my requirements.
>
> If so, I'd be looking to convert the assembler to use it (and 
> improving it where necessary). Do you happen to know the reasons why 
> the assembler isn't using this bit of LLVM?
>

The assembler predates it.

  -Hal

> Thanks!
> Sanne
>
>
> From: Quentin Colombet
> Sent: Monday, 13 March, 15:22
> Subject: Re: [cfe-dev] [RFC] improvements to LLVM diagnostic 
> infrastructure
> To: Sanne Wouda
> Cc: llvm-dev at lists.llvm.org, cfe-dev at lists.llvm.org, nd
>
> Hi Sanne,
>
>> On Mar 13, 2017, at 7:41 AM, Sanne Wouda via cfe-dev 
>> <cfe-dev at lists.llvm.org <mailto: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
>>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170313/e64b1f45/attachment.html>