--- Comment #15 from bangerth at gmail dot com 2010-04-05 15:28 ---
FWIW, let me say that I believe that few people use -Wfatal-errors. Most of
the time, experienced programmers are able to fix multiple bugs in one
go-around
if they get to see all error messages, and the less experienced
--- Comment #14 from jason at gcc dot gnu dot org 2010-01-29 17:11 ---
And closing.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITIN
--- Comment #13 from jason at gcc dot gnu dot org 2010-01-29 17:10 ---
Created an attachment (id=19753)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19753&action=view)
work snapshot
Here's a final snapshot of the work I did on this if anyone ever feels like
picking it up again.
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-04 22:36 ---
Paolo's point about -Wfatal-errors makes me inclined to leave this alone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-04 20:18
---
(In reply to comment #10)
> At least that way you'll know the error is always at the top, instead of at
> some point between the end of the compile line and the next prompt.
Yes, but is this true with -Wfatal
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-11-04 19:53 ---
FWIW, I think even in the case that the total message (error + context) is more
than can fit at one time on the current terminal window, it is advantageous to
have the fixed length part (error) first, and then the var
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-04 02:36
---
You know what? I'm a bit unsure about the issue itself... I mean, let's assume
the user passes in any case -Wfatal-errors, which, as we discussed already, is
the only way to manage those huge series of error me
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-11-03 23:43 ---
Hey, hey! Cool.
So, pre-patch I get this for the attached (get.ii.bz2) file:
$bld/H-x86-gcc.20091103/bin/g++ -g -std=gnu++0x -Wall -Wfatal-errors get.ii
In file included from
/mnt/share/src/gcc/libstdc++-v3/testsuite
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-04 02:22
---
Yes, I think the last message from Benjamin summarizes well the enhancement we
have been thinking about: first the error (file, line number and actual error
message), then all the rest.
--
http://gcc.gnu.o
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-11-03 23:36 ---
Created an attachment (id=18960)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18960&action=view)
pre-processed source to reproduce diagnostic
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-03 14:45 ---
(In reply to comment #3)
> but moves all the other includes after the error.
Er, "all the other instantiations".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-03 14:42
---
Thanks Jason for working on this. I want to play with the patch, but give me
say half a day at least, maybe in the meanwhile Benjamin can also start
experimenting a bit with it...
--
http://gcc.gnu.org/bug
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-03 14:39 ---
This patch leaves the includes and the inner context (function or class
instantiation) above the error, but moves all the other includes after the
error. How does it look to you?
--
jason at gcc dot gnu dot org ch
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-03 14:36 ---
Created an attachment (id=18955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18955&action=view)
better patch
This one actually tests cleanly.
--
jason at gcc dot gnu dot org changed:
What|R
--- Comment #1 from jason at gcc dot gnu dot org 2009-11-02 23:44 ---
Created an attachment (id=18952)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18952&action=view)
prototype patch
Something like this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
16 matches
Mail list logo
