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

Quentin Colombet qcolombet at apple.com
Fri Jul 19 18:46:39 PDT 2013


Hi Chandler,

> Le 19 juil. 2013 à 17:48, Chandler Carruth <chandlerc at google.com> a écrit :
> 
> 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.
Fair enough.

Let us go back into the discussion then :).

The general question now would be what should we expose and how could we make it easily available to a front-end.

Also one thing that is missing, what do we do if there is not a front end?
In other words how are we supposed to abort if something bad happen when nobody is querying for diagnostics?

Q.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/2686c307/attachment.html>


More information about the llvm-dev mailing list