Re: [C++ PATCH] Don't allow taking the address of an rvalue reference (PR c++/35153)

["Doug Gregor" <doug dot gregor at gmail dot com>]

On Feb 18, 2008 8:07 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Doug Gregor wrote:
>
> > 2008-02-15  Douglas Gregor  <doug.gregor@gmail.com>
> >
> >       PR c++/35153
> >       * typeck.c (build_x_unary_op): Don't allow us to take the address
> >       of an rvalue that's hiding being an INDIRECT_REF. We can only end
> >       up triggering that error when we have some kind of rvalue
> >       reference.
> >
> > 2008-02-15  Douglas Gregor  <doug.gregor@gmail.com>
> >
> >       PR c++/35153
> >       * g++.dg/cpp0x/rref-35153.C: New.
>
> Why not put this in build_unary_op?  That's where we do most of the
> other checks -- though, of course, OFFSET_REF and TARGET_EXPR are in
> build_x_unary_op, for reasons I don't really understand.

I tried putting it in build_unary_op the first time, and..

> So, I think your check should go in build_unary_op -- unless for some
> reason it can't, like if there's a compiler-generated need to take the
> address of the rvalue reference,

Bingo. This is exactly what happened---compiler-generated code was
going through build_unary_op, and triggering this error when it was
okay to take the address of the result.

> and we're going through build_unary_op
> instead of build_address.

I didn't think of that. build_address doesn't do the
ADDR_EXPR/INDIRECT_REF simplification, which some of the current
callers of build_unary_op(ADDR_EXPR...) might rely on. So, I can try
to change the compiler-generated calls to build_unary_op(ADDR_EXPR...)
into build_address, and move the address-of-rvalue check into
build_unary_op, if you'd still prefer that implementation.

  - Doug