Info diagnostic level

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.

Thanks,
Victor

info-diag.patch (521 Bytes)

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.

Isn't Note sufficient?

Sebastian

I thought about using Note, but unfortunately it is not sufficient, because a note is virtually attached to the previous diagnostic and is ignored if the previous one is ignored. This is not a desired behaviour when one needs to output a standalone informational diagnostic.

Victor

2009/11/20 Sebastian Redl <sebastian.redl@getdesigned.at>

I'm okay with adding another diagnostic level. Some other compilers have "remarks"; I'd slightly prefer that name over "info". However, to include your patch in Clang we need to fully integrate this new kind of diagnostic. In addition to adding an enumerator to Level, we need to answer a few questions:

   - How do all of the existing diagnostic clients format infos/remarks?
   - Are infos/remarks counted in the diagnostic count?
   - How do infos/remarks behave w.r.t. -Werror?

  - Doug

I think that remarks (I prefer the name) should not trigger -Werror;
most remarks should, in my opinion be things that indicate nothing is
wrong, and might in fact be helpful. A good example might be
suggestions for changes that would increase the optimizer's potential
(such as marking a variable as restrict). I suppose someone might
really want -Wremark-error, but that should be a separate flag.

As far as counting goes, I think that all remarks ought to be disabled
by default, so including them in the diagnostic count won't be much of
an issue.

Sean

Delphi called these 'hints' and they included things that were semantically correct, but bad style. It was quite a nice feature, especially for people learning the language.

David

-- Sent from my Difference Engine

The name Remarks is OK for me.
I see one of the uses of this in for the output of progress information, for example, to report which file is being compiled as VS does. However it can be seen as a general output facility that uses diagnostic instead of writing to the stdout.
Therefore I think that this kind of diagnostic unlike errors, warnings or notes should be output by existing clients with minimal
formatting (without prepending "remark: " or whatever, only the location if it is specified).
For the same reason I’d say that it shouldn’t be counted in the diagnostic count and should be never turned into
errors with -Werror.
Does it make sense?

Victor

2009/11/20 Douglas Gregor <dgregor@apple.com>

Hi Victor,

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

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
callback mechanism).

- Daniel

Hi Daniel,

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.

Best regards,
Victor

2009/11/22 Daniel Dunbar <daniel@zuster.org>