[LLVMdev] [RFC] Add warning capabilities in LLVM.

[Chandler Carruth]

On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>
> On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com>
> wrote:
>
> ** 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.)
>
>
> I think we definitely need this.  In fact, I tried adding something simple
> earlier this year but gave up when I realized that the task was bigger than
> I expected.  We already have a hook for diagnostics that can be easily
> extended to handle warnings as well as errors (which is what I tried
> earlier), but the problem is that it is hardwired for inline assembly
> errors.  To do this right, new warnings really need to be associated with
> warning groups so that can be controlled from the front-end.
>
> I agree with Eli that there probably won’t be too many of these.  Adding a
> few new entries to clang’s diagnostic .td files would be fine, except that
> the backend doesn’t see those.  It seems like we will need something in
> llvm that defines a set of “backend diagnostics”, along with a table in the
> frontend to correlate those with the corresponding clang diagnostics.  That
> seems awkward at best but maybe it’s tolerable as long as there aren’t many
> of them.
>

I actually think this is the wrong approach, and I don't think it's quite
what Eli or I am suggestion (of course, Eli may want to clarify, I'm only
really clarifying what *I'm* suggesting.

I think all of the warnings should be in the frontend, using the standard
and existing machinery for generating, controlling, and displaying a
warning. We already know how to do that well. The difference is that these
warnings will need to query the LLVM layer for detailed information through
some defined API, and base the warning on this information. This
accomplishes two things:

1) It ensures the warning machinery is simple, predictable, and integrates
cleanly with everything else in Clang. It does so in the best way by simply
being the existing machinery.

2) It forces us to design reasonable APIs in LLVM to expose to a FE for
this information. A consequence of this will be to sort out the layering
issues, etc. Another consequence will be a strong chance of finding general
purpose APIs in LLVM that can serve many purposes, not just a warning.
Consider JITs and other systems that might benefit from having good APIs
for querying the size and makeup (at a high level) of a generated function.

A nice side-effect is that it simplifies the complexity involved for simple
warnings -- now it merely is the complexity of exposing the commensurately
simple API in LLVM. If instead we go the route of threading a FE interface
for *reporting* warnings into LLVM, we have to thread an interface with
sufficient power to express many different concepts.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/689a5430/attachment.html>