https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
Theodore.Papadopoulo at inria dot fr changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Theodore.Papadopoulo@inria.
| |fr
--- Comment #12 from Theodore.Papadopoulo at inria dot fr ---
Sorry if this is message slightly diverges from the technical aspects...
While I'm used to parse the g++ messages, I must agree that sometimes it is too
much and not straight to the point... There has to be a way to make messages a
little more readable.
For one thing even finding the boundaries between two messages is not always
visually trivial. It might not be very difficult (with colors or blank lines or
...) to make this much easier to parse.
I must also say that in extreme cases (like eg some boost spirit stuff or more
generally some meta-template code), the error stack is huge and I have
appreciated what they do in boost spirit: In the code there is a comment that
states "if you have an error at the next line, this usually means you have done
that mistake".
Long before I was aware of static_assert, I considered implementing some kind
of pragma to achieve these high level messages, because this helps a lot. The
static_assert solution evoked above might be a way to implement this without
relying to extensions, which is nice... The only thing I regret slightly is the
verbiage related to the static_assert, which for me is an implementation detail
(of the way the error was generated). I understand very well that's the way
static_assert is supposed to work, but I would prefer a more normally looking
message, or maybe some visually easy to identify "hint" that would be provided
in addition to errors messages and that can help the developer at least in the
trivial cases...
I think that the quality of the error messages is very important for a compiler
and understand that this is a very difficult topic. I also know that very
important improvements were made these last two years, and I take the
opportunity to thank all those involved in that work.
Yet we should never forget that error messages must have two qualities:
- Allow to identify the cause of a problem (completeness).
- Allow to do so as quickly as possible (efficiency).
