[RFC] improvements to LLVM diagnostic infrastructure

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[RFC] improvements to LLVM diagnostic infrastructure

Jacob Carlborg via cfe-dev

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 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] improvements to LLVM diagnostic infrastructure

Jacob Carlborg via cfe-dev
Hi Sanne,

On Mar 13, 2017, at 7:41 AM, Sanne Wouda via cfe-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC] improvements to LLVM diagnostic infrastructure

Jacob Carlborg via cfe-dev

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?

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: [hidden email], [hidden email], nd

Hi Sanne,

On Mar 13, 2017, at 7:41 AM, Sanne Wouda via cfe-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] [RFC] improvements to LLVM diagnostic infrastructure

Jacob Carlborg via cfe-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: [hidden email], [hidden email], nd

Hi Sanne,

On Mar 13, 2017, at 7:41 AM, Sanne Wouda via cfe-dev <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev





_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...