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

[David Blaikie]

On Wed, Jul 24, 2013 at 9:37 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Jul 22, 2013, at 2:25 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
>
> On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>>
>> >> This is pretty much the same as what Quentin proposed (with the
>> >> addition of the enum), isn't it?
>> >>
>> >
>> > Pretty close yeah.
>> >
>>
>> Another thought and alternate strategy for dealing with these sorts of
>> things:
>>
>> A much more broad set of callback machinery that allows the backend to
>> communicate values or other information back to the front end that can
>> then decide what to do. We can define an interface around this, but
>> instead of having the backend vending diagnostics we have the callback
>> take a "do something with this value" which can just be "communicate
>> it back to the front end" or a diagnostic callback can be passed down
>> from the front end, etc.
>>
>> This will probably take a bit more design to get a general framework
>> set up, but imagine the usefulness of say being able to automatically
>> reschedule a jitted function to a thread with a larger default stack
>> size if the callback states that the thread size was N+1 where N is
>> the size of the stack for a thread you've created.
>
>
> FWIW, *this* is what I was trying to get across. Not that it wouldn't be a
> callback-based mechanism, but that it should be a fully general mechanism
> rather than having something to do with warnings, errors, notes, etc. If a
> frontend chooses to use it to produce such diagnostics, cool, but there are
> other use cases that the same machinery should serve.
>
>
> How about this: keep the jist of the current API, but drop the "warning"- or
> "error"-ness of the API.  Instead, the backend just includes an enum value
> (plus string message for extra data).  The frontend makes the decision of
> how to render the diagnostic (or not, dropping them is fine) along with how
> to map them onto warning/error or whatever concepts they use.

For the cases where backend diagnostics make sense (such as asm
parsing or the like) it'll make sense for the backend to include a
warning/error classification (& I don't think its absence is the key
to what Chandler's getting at - the point is to avoid phrasing things
as "diagnostics" from LLVM whenever it's possible to expose some
broader information & let frontends do whatever they want with it) -
that'll save every frontend having to make a, probably very similar,
classification - epsecially in the case of errors it seems unlikely a
frontend could do anything else but classify it as an error. The
diagnostic blob should also include some 'id' though, yes, so
frontends can, in a pinch, classify things differently (we have an
LLVM flag "-fatal-assembly-warnings" or the like - we could kill that
& just have the client callback on diagnostics elevate the warning to
an error (indeed Clang already has infrastructure for promoting
warnings to errors, so that should be used - no need for other
implementations of the same idea)).

I'm not quite clear from your suggestion whether you're suggesting the
backend would produce a complete diagnostic string, or just the
parameters - requiring/leaving it up to the frontend to have a full
textual string for each backend diagnostic with the right number of
placeholders, etc. I'm sort of in two minds about that - I like the
idea that frontends keep all the user-rendered text (means
localization issues are in one place, the frontend - rather than
ending up with english text backend diagnostics rendered in a
non-english client (yeah, pretty hypothetical, I'm not sure anyone has
localized uses of LLVM)). But this does mean that there's no "free
ride" - frontends must have some explicit handling of each backend
diagnostic (some crappy worst-case fallback, but it won't be a useful
message).

& I don't think this avoids the desire to have non-diagnostic
callbacks whenever possible (notify of interesting things, frontends
can decide whether to use that information to emit a diagnostic based
on some criteria or behave differently in another way).