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

["jason at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #30 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-02 05:16:05 UTC ---
(In reply to comment #26)
> 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.

I think I've said before that caret should default to on when the output is a
terminal.

> That and that moving
> line-map out of libcpp to create a source-location library has been rejected in
> the past.

I don't remember the discussion about this.  What was the goal?

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

Well, we didn't have the competitive pressure from clang in the past 25 years;
now we do.

Good column information is equivalent to caret diagnostics; the column number
tells you where the caret goes, so an IDE can put the cursor there.  As I've
suggested before, one quick way to get caret diagnostics given the column
information would be to write a quick perl postprocessor that just prints the
designated line and puts a caret under the designated column.

Range highlighting like clang has is something further; we would need two
source locations per expression, rather than the one we currently have.

And G++ still needs some work to track expression locations better, it hasn't
gotten as much work on that as the C front end.