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

Chandler Carruth chandlerc at google.com
Fri Jul 19 17:48:44 PDT 2013

Sorry for the delays, just haven't been able to get back around to this. My
silence isn't about not caring.

On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <qcolombet at apple.com>wrote:

> Like I summed up in my previous email (see below), there are two
> orthogonal approaches to this problem.
> I have chosen the second one (extend the reporting already used for inline
> asm).
> Regarding the first approach (front-end querying the back-end to build up
> diagnostic), it needs further discussion if anyone wants to go in that
> direction. Although I think this is interesting, I leave that for someone
> else.

I really don't like the second approach.

Fundamentally, it increasingly couples LLVM to Clang's warning
infrastructure and I think that's a bad thing. I think we are better served
by designing good interfaces for the frontend and the backend to
communicate in order for different frontends to provide different types and
kinds of information to users based on their needs.

Bob described one potential API for this, but I think there are much better
ones. I don't think we have to be constrained by the idea of using a pass
to compute and communicate this information -- there are other approaches.
I haven't thought about them because I haven't designed such an interface.
If I had, I would just contribute it. I do think that this is the correct
design direction though, as I don't think that there is one unified way to
represent diagnostics in the backend, or if there is I don't tihnk we have
any idea what it looks like.

Inline assembly is more of a special case than anything else. I don't
really see why the right path forward is to design a generic framework
around what was originally built for its specific purpose.

If anything, I think the design you are pursuing is strictly more complex
and invasive, and without any tangible benefits as a consequence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/f235fc30/attachment.html>

More information about the llvm-dev mailing list