Sorry, I've been busy with my main project and didn't follow the list for some time.
The progress information example was probably not a good one since it is indeed structured and better handled differently. However, I want to use diagnostics to return unstructured information. My use case is the same as you described. I want to output various information from the driver program of my translator and was thinking of using Diagnostics instead of writing to stderr for this.
Can you explain a bit more about what you want to do with this?
If you want to return structured information (e.g., progress
information), I'm not sure adding another diagnostic level is the
right approach, since it is too generic and clients won't necessarily
know how to deal with it (from an API level). If it is unstructured,
then we need to clarify what the level means w.r.t. the existing
The reason I ask is that the driver has some similar issues where it
currently dumps information to stderr (-v, -print-search-dirs, etc).
In theory, I'd like to not have this buried in the Driver library but
let the client have control over it, but I haven't decided how I want
to do this (the obvious approaches are to extend Diagnostics, or use
special diagnostic classes for it, or alternately use a different
> I am actively using the clang's Basic library in my project and in
> particular its diagnostic part which is great.
> However it has the following limitation: it is not possible to report an
> "informational" message which is neither warning nor error through it. While
> clang doesn't need this functionality it may be useful for other users (me
> being one of them :)) without any overhead for clang. The attached patch
> introduces the Info diagnostic level.