Re: PR symtab/14441 - rvalue references

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 29 October 2012 14:25, Tom Tromey wrote:
> Jonathan> Before I continue altering every function that checks TYPE_CODE_REF,
> Jonathan> is my approach the right one?  Is adding TYPE_CODE_RVAL_REF and
> Jonathan> touching dozens of functions the best approach, or should I go back to
> Jonathan> my first attempt and just fix the few places that need to handle
> Jonathan> lvalue and rvalue references differently?
>
> I would accept either one.  Abstractly, I suppose a new type code would
> be more in keeping with the current design.  But I think the other
> choice would be ok, too, if it is a reasonably accurate model of C++.  I
> don't know enough about rvalue references to say whether this is the
> case.

I believe it is the case.

An rvalue-reference can only bind to an rvalue, however once it's
bound to a variable the reference *is* an lvalue, so for all intents
and purposes GDB could treat variables of rvalue-reference type
exactly the same as lvalue references, except for showing "&&" when
printing types.

For example:

struct X { };

X
f (X&& param)
{
  // param is an lvalue here!
  return param;  // return a copy
}

X
g (void)
{
  X x;
  return x;  // return a copy
 }

int main()
{
  X&& rv = f ( g () );
  // rv is an lvalue!
  X* addr = &rv;  // OK to take address
}

In this example, although the function parameter param and variable rv
are rvalue-references and bound to rvalues, they are named variables
and are lvalues.  i.e. the act of binding an rvalue reference to an
rvalue, thereby giving it a name, makes it an lvalue.

Which is why my gut feeling (having barely looked at the gdb code two
days ago) is that rvalue references don't need any special handling
different to existing TYPE_CODE_REF variables, except for "ptype"
printing "X&&" instead of "X&"

Unfortunately my first attempt at doing that didn't work, so I started
adding TYPE_CODE_RVAL_REF and handling it everywhere ... but I'm
having second thoughts.