This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/49152] Unhelpful diagnostic for iterator dereference


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152

--- Comment #26 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> 2012-04-01 11:24:14 UTC ---
(In reply to comment #24)
> Personally, I don't believe Gaby is open to other solutions outside the
> full-fledged "caret diagnostics" context, thus for the time being at least I'm
> personally going to stand to his judgment (as diagnostics maintainer).

The caret is not a solution to this problem, because what Gabriel wants is to
not reconstruct expressions ONLY when the caret is shown, but he has said in
the past that the caret should default to OFF to not change the current output
for IDEs and other software parsing the output of gcc like emacs, so we are
back to printing the monsters mentioned above by default.

This is another reason why I am not motivated to keep working on the caret.
What is the point if it is going to default to OFF anyway? That and that moving
line-map out of libcpp to create a source-location library has been rejected in
the past.

And there is no compromise solution. The only argument in favor of
pretty-printing expressions is to help identify the culprit in a complex
expression, so printing only expressions that have non-expression operands will
surely be rejected by Gabriel.

Even if the caret was the solution, nobody has worked on it in the last 25
years, and now that we have good column information, I don't expect that there
will be anyone working on it in the next 25. Specially now that there is a
better alternative, because if you want nice diagnostics, why don't just use
Clang?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]