[Bug c++/41884] New: diagnostics: error vs. context

[Bug c++/41884] New: diagnostics: error vs. context

[bkoz at gcc dot gnu dot org]

This is a tracker bug for a conversation held last week between Paolo, Jason,
and myself during the ISO C++ meeting in Santa Cruz. 

Is there a way to better disambiguate the error from the error context? One
thing discussed that seemed like it had potential was to

error:

first and then provide

instantiating context:

next, instead of the status quo approach. So,

In file included from
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc:27:0:

/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function 'typename std::unique_future<_Res>::_Mover::__rval_type
std::unique_future<_Res>::get() [with _Res = int, typename
std::unique_future<_Res>::_Mover::__rval_type = int]':

/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc:50:12:
  instantiated from here

/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:451:64:
error: no matching function for call to 'std::__future_base::_Move_result<int,
true>::_S_move(std::__future_base::_Result<int>&)'

/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:126:14:
note: candidates are: static _Res std::__future_base::_Move_result<_Res,
true>::_S_move(_Res) [with _Res = int]

compiler exited with status 1

Might look like
<b>error</b>: no matching function for call to
'std::__future_base::_Move_result<int,
true>::_S_move(std::__future_base::_Result<int>&)'

 note: candidates are: static _Res std::__future_base::_Move_result<_Res,
true>::_S_move(_Res) [with _Res = int]
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:126:14:
In file included from /mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads
 note: instantiated from here
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc:50:12: 
/packaged_task/members/reset.cc:27:0:
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function 'typename std::unique_future<_Res>::_Mover::__rval_type
std::unique_future<_Res>::get() [with _Res = int, typename
std::unique_future<_Res>::_Mover::__rval_type = int]':


-- 
           Summary: diagnostics: error vs. context
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bkoz at gcc dot gnu dot org


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu 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    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18952|0                           |1
        is obsolete|                            |


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

-- 

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                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-11-03 14:38:07
               date|                            |


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

------- 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 changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


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

[Bug c++/41884] diagnostics: error vs. context

[paolo dot carlini at oracle dot com]

------- 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/bugzilla/show_bug.cgi?id=41884

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

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

[Bug c++/41884] diagnostics: error vs. context

[bkoz at gcc dot gnu dot org]

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

[Bug c++/41884] diagnostics: error vs. context

[bkoz at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]



------- 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/30_threads/unique_future/members/get.cc:27:0:
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function ‘typename std::unique_future<_Res>::_Mover::__rval_type
std::unique_future<_Res>::get() [with _Res = int, typename
std::unique_future<_Res>::_Mover::__rval_type = int]’:
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/unique_future/members/get.cc:40:12:
  instantiated from here
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:445:64:
error: no matching function for call to ‘std::__future_base::_Move_result<int,
true>::_S_move(std::__future_base::_Result<int>&)’
compilation terminated due to -Wfatal-errors.

Compared with post-patch:
In file included from
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/unique_future/members/get.cc:27:0:
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function ‘typename std::unique_future<_Res>::_Mover::__rval_type
std::unique_future<_Res>::get() [with _Res = int, typename
std::unique_future<_Res>::_Mover::__rval_type = int]’:
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:445:64:
error: no matching function for call to ‘std::__future_base::_Move_result<int,
true>::_S_move(std::__future_base::_Result<int>&)’
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/unique_future/members/get.cc:40:3:
  instantiated from here
compilation terminated due to -Wfatal-errors.

I still think that the full error first, then the context would be better:

/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:445:64:
error: no matching function for call to ‘std::__future_base::_Move_result<int,
true>::_S_move(std::__future_base::_Result<int>&)’
In file included from
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/unique_future/members/get.cc:27:0:
/mnt/share/bld/gcc/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function ‘typename std::unique_future<_Res>::_Mover::__rval_type
std::unique_future<_Res>::get() [with _Res = int, typename
std::unique_future<_Res>::_Mover::__rval_type = int]’:
/mnt/share/src/gcc/libstdc++-v3/testsuite/30_threads/unique_future/members/get.cc:40:12:
  instantiated from here
compilation terminated due to -Wfatal-errors.


-- 


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

[Bug c++/41884] diagnostics: error vs. context

[paolo dot carlini at oracle dot com]

------- 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.org/bugzilla/show_bug.cgi?id=41884

[Bug c++/41884] diagnostics: error vs. context

[paolo dot carlini at oracle dot com]

------- 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 messages. Now, in the current
situation, even if the messages are very long, the last few lines, which you
can read close to your new prompt contain the actual error: message line. On
the other hand, if we reverse completely the order, for short messages the
output is cleaner, because you get first the error: and then the "details", so
to speak, but for very long error messages there is the important risk that the
line containing error: exits the shell from the top! I'm not sure I have been
able to fully explain what I mean...


-- 


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

[Bug c++/41884] diagnostics: error vs. context

[bkoz at gcc dot gnu dot org]

------- 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 variable length part
(context) next.

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.

-benjamin


-- 


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

[Bug c++/41884] diagnostics: error vs. context

[paolo dot carlini at oracle dot com]

------- 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-errors? Maybe I should just take the time to
experiment a bit more, but the reason why I posted my mumblings last night, is
that it occurred to me that probably it's simply not true with -Wfatal-errors,
that is, the single error is always exactly the last printed thing, close to
the new prompt. For example, take the messages in your Comment #7, and imagine
for a moment each is 50 lines, not uncommon with templates, which one would be
more quickly informative in your ~30 lines window? That said, I agree there are
also reasons to reason: first print the error, and then all the additional
details, this strategy being very effective for short overall messages, fitting
in the window. However, I don't think all the users of GCC can agree, or in
large majority at least, about which one is best. In conclusion, my current
idea is: either have a switch to choose case by case, or give the issue a bit
more thought before changing a very old behavior.


-- 


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

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


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18955|0                           |1
        is obsolete|                            |


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

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

------- 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|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug c++/41884] diagnostics: error vs. context

[bangerth at gmail dot com]

------- 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 programmers
likely don't know about -Wfatal-errors.

This said, I quite frequently find it annoying that the actual error message
is so hard to find between the text printed above and below it. A defined
place either at the top or at the bottom would be highly useful in my mind.

W.


-- 


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