]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: implicit move with throw [PR113853]
authorMarek Polacek <polacek@redhat.com>
Wed, 14 Feb 2024 22:53:52 +0000 (17:53 -0500)
committerMarek Polacek <polacek@redhat.com>
Fri, 16 Feb 2024 17:09:01 +0000 (12:09 -0500)
commit254ff3d0e34835b4de93d5e5763a7366dc7d989d
tree4d628cab998fff9efcc3ea03563e74bd424b06ab
parent5286b0761b5dfac4348d1c5bfdcc162a66f338ee
c++: implicit move with throw [PR113853]

Here we have

  template<class T>
  auto is_throwable(T t) -> decltype(throw t, true) { ... }

where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen.  Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if

"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."

I worked out that it's trying to say that given

  struct X {
    X();
    X(const X&);
    X(X&&) = delete;
  };

the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.

  void f ()
  try {
    X x;
    throw x;  // use of deleted function
  } catch (...) {
  }

Whereas here:

  void g (X x)
  try {
    throw x;
  } catch (...) {
  }

the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.

The current code also doesn't seem to handle

  void h (X x) {
    void z (decltype(throw x, true));
  }

where there's no enclosing lambda or sk_try so we should move.

I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.

PR c++/113789
PR c++/113853

gcc/cp/ChangeLog:

* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
gcc/cp/typeck.cc
gcc/testsuite/g++.dg/cpp0x/sfinae69.C
gcc/testsuite/g++.dg/cpp0x/sfinae70.C [new file with mode: 0644]
gcc/testsuite/g++.dg/cpp0x/sfinae71.C [new file with mode: 0644]
gcc/testsuite/g++.dg/cpp0x/sfinae72.C [new file with mode: 0644]
gcc/testsuite/g++.dg/cpp2a/implicit-move4.C [new file with mode: 0644]