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

[David Blaikie]

On Wed, Jul 24, 2013 at 10:23 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jul 24, 2013, at 10:16 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 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.
>>
>> 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 have a specific proposal in mind, other than thinking along the exact same lines as you above.  :)
>
> The best approach is probably hybrid: the diagnostic producer can produce *both* a full string like today, as well as an "ID + enum" pair.  This way, clang can use the later, but llc (as one example of something we want to keep simple) could print the former, and frontends that get unknown enums could fall back on the full string.

Fair-ish. If it were just for the sake of llc it'd be hard to justify
having the strings in LLVM rather than just in llc itself, but
providing them as fallbacks is probably reasonable/convenient & not
likely to be a technical burden. Hopefully if we wanted that we'd
still put something in Clang to maintain the frontend diagnostic line
rather than letting it slip.

>
>> & 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).
>
> Sure, but we also don't want to block progress in some area because we have a desire to solve a bigger problem.

Sure enough - I think the only reason to pre-empt the bigger problem
is to ensure that the immediate progress doesn't lead to bad
implementations of those bigger issues being committed due to
convenience. Ensuring that the solution we implement now makes it hard
to justify (not hard to /do/ badly, just hard to justify doing it
badly by ensuring that the right solution is convenient/easy) taking
shortcuts later would be good.

That might just be the difference between having a function pointer
callback for the diagnostic case and instead having a callback type
with the diagnostic callback as the first one, with the intent to add
more in cases where backend-diagnostics aren't the right tool. That
way we have an callback interface we can easily extend. (ideally I'd
love to have two things in the callback interface early, as an example
- but that's not necessary & probably won't happen)

I don't know enough about the particular things Quentin's planning to
implement to know whether any of them fall into the "probably
shouldn't be an LLVM diagnostic" bag.