[LLVMdev] [RFC] Add warning capabilities in LLVM.
Eli Friedman
eli.friedman at gmail.com
Tue Jul 16 17:51:40 PDT 2013
On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> Hi,
>
> I would like to start a discussion about error/warning reporting in LLVM and
> how we can extend the current mechanism to take advantage of clang
> capabilities.
>
>
> ** Motivation **
>
> Currently LLVM provides a way to report error either directly (print to
> stderr) or by using a user defined error handler. For instance, in inline
> asm parsing, we can specify the diagnostic handler to report the errors in
> clang.
>
> The basic idea would be to be able to do that for warnings too (and for
> other kind of errors?).
> A motivating example can be found with the following link where we want LLVM
> to be able to warn on the stack size to help developing kernels:
> http://llvm.org/bugs/show_bug.cgi?id=4072
>
> By adding this capability, we would be able to have access to all the nice
> features clang provides with warnings:
> - Promote it to an error.
> - Ignore it.
>
>
> ** Challenge **
>
> To be able to take advantage of clang framework for warning/error reporting,
> warnings have to be associated with warning groups.
> Thus, we need a way for the backend to specify a front-end warning type.
>
> The challenge is, AFAICT (which is not much, I admit), that front-end
> warning types are statically handled using tablegen representation.
>
>
> ** Advices Needed **
>
> 1. Decide whether or not we want such capabilities (if we do not we may just
> add sporadically the support for a new warning/group of warning/error).
> 2. Come up with a plan to implement that (assuming we want it).
The frontend should be presenting warnings, not the backend; adding a
hook which provides the appropriate information shouldn't be too hard.
Warnings coming out of the backend are very difficult to design well,
so I don't expect we will add many. Also, keep in mind that the
information coming out of the backend could be used in other ways; it
might not make sense for the backend to decide that some piece of
information should be presented as a warning. (Consider, for example,
IDE integration to provide additional information about functions and
loops on demand.)
-Eli
On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> Hi,
>
> I would like to start a discussion about error/warning reporting in LLVM and
> how we can extend the current mechanism to take advantage of clang
> capabilities.
>
>
> ** Motivation **
>
> Currently LLVM provides a way to report error either directly (print to
> stderr) or by using a user defined error handler. For instance, in inline
> asm parsing, we can specify the diagnostic handler to report the errors in
> clang.
>
> The basic idea would be to be able to do that for warnings too (and for
> other kind of errors?).
> A motivating example can be found with the following link where we want LLVM
> to be able to warn on the stack size to help developing kernels:
> http://llvm.org/bugs/show_bug.cgi?id=4072
>
> By adding this capability, we would be able to have access to all the nice
> features clang provides with warnings:
> - Promote it to an error.
> - Ignore it.
>
>
> ** Challenge **
>
> To be able to take advantage of clang framework for warning/error reporting,
> warnings have to be associated with warning groups.
> Thus, we need a way for the backend to specify a front-end warning type.
>
> The challenge is, AFAICT (which is not much, I admit), that front-end
> warning types are statically handled using tablegen representation.
>
>
> ** Advices Needed **
>
> 1. Decide whether or not we want such capabilities (if we do not we may just
> add sporadically the support for a new warning/group of warning/error).
> 2. Come up with a plan to implement that (assuming we want it).
>
>
> Thanks for the feedbacks.
>
> Cheers,
>
> -Quentin
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list