c++/10345: [3.2/3.3/3.4 regression] Misleading error message for binding rvalue to reference

[bangerth@ticam.utexas.edu]

>Number:         10345
>Category:       c++
>Synopsis:       [3.2/3.3/3.4 regression] Misleading error message for binding rvalue to reference
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 07 22:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Wolfgang Bangerth
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
I think this has come up before, but again (and with an
additional problem noticed below): this code
---------------------------int foo();
int bar(int &p);

const int x = bar (foo());
---------------------------
is indeed wrong, since we try to bind a temporary to a 
non-constant references. However, I think that the error
message we get since 3.0 times is really unhelpful:

g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
x.cc:4: error: could not convert `foo()()' to `int&'
x.cc:2: error: in passing argument 1 of `int bar(int&)'

If one doesn't already know what's going on, then this
is unintelligible, since in particular it does not state
the return type of foo(), which is what this is all
about. I rate this as a regression, since 2.95 was quite
clear about this:
g/x> c++ -c x.cc
x.cc:4: initialization of non-const reference type `int &'
x.cc:4: from rvalue of type `int'
x.cc:2: in passing argument 1 of `bar(int &)'

The present message text comes from here:
------------------------------
tree
initialize_reference (tree type, tree expr, tree decl)
{
  tree conv;

  if (type == error_mark_node || error_operand_p (expr))
    return error_mark_node;

  conv = reference_binding (type, TREE_TYPE (expr), expr, LOOKUP_NORMAL);
  if (!conv || ICS_BAD_FLAG (conv))
    {
      error ("could not convert `%E' to `%T'", expr, type);
      return error_mark_node;
    }
------------------
Maybe there is a way to improve the wording here.


Another point (probably low hanging fruit for someone
looking at this): in our present message, we have    `foo()()'
Note the double parentheses. This happens somewhere in
the CALL_EXPR part of dump_expr in error.c, but I can't
read what is really going on there.

W.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: