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

[Chris Lattner]

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.

> & 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.

-Chris