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

[Eli Friedman]

On Fri, Jul 19, 2013 at 6:46 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 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?

We can write a default diagnostic handler suitable for something like
llc, where there isn't really any source code to point at.

-Eli