On Wed, 12 Oct 2022 at 20:39, Marek Polacek <pola...@redhat.com> wrote:
>
> As I promised in
> <https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603189.html>,
> I'd like to update our GCC 13 porting_to.html with the following note.
>
> Does this look OK to commit? Thanks,
>
> diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
> index 84a00f21..243ed29d 100644
> --- a/htdocs/gcc-13/porting_to.html
> +++ b/htdocs/gcc-13/porting_to.html
> @@ -42,5 +42,57 @@ be included explicitly when compiled with GCC 13:
> </li>
> </ul>
>
> +<h3 id="two-stage-or">Two-stage overload resolution for implicit move
> removed</h3>
> +<p>
> +GCC 13 removed the two-stage overload resolution when performing
> +implicit move, whereby the compiler does two separate overload resolutions:
> +one treating the operand as an rvalue, and then (if that resolution fails)
> +another one treating the operand as an lvalue. In the standard this was
> +introduced in C++11 and implemented in gcc in
> +<a
> href="https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4ce8c5dea53d80736b9c0ba6faa7430ed65ed365";>
> +r251035</a>. In
> +<a
> href="https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1722e2013f05f1f1f99379dbaa0c0df356da731f";>
> +r11-2412</a>, the fallback overload resolution was disabled in C++20 (but
> +not in C++17). Then C++23 <a href="https://wg21.link/p2266";>P2266</a>
> +removed the fallback overload resolution, and changed the implicit move
> +rules once again.
> +</p>
> +<p>
> +The two overload resolutions approach was complicated and quirky, so users
> +should transition to the newer model. This change means that code that
> +previously didn't compile in C++17 will now compile, for example:</p>
> +
> +<pre><code>
> + struct S1 { S1(S1 &&); };
> + struct S2 : S1 {};
> +
> + S1
> + f (S2 s)
> + {
> + return s; // OK, derived-to-base, use S1::S1(S1&&)
> + }
> +</code></pre>
> +
> +<p>
> +And conversely, code that used to work in C++17 may not compile anymore:
> +</p>
> +
> +<pre><code>
> + struct W {
> + W();
> + };
> +
> + struct F {
> + F(W&);
> + F(W&&) = delete;
> + };
> +
> + F fn ()
> + {
> + W w;
> + return w; // use w as rvalue -> use of deleted function F::F(W&&)
Deleted move constructors are an abomination, and should never occur
in real code. I'm not sure using one even in an example like this
should be encouraged. The example added by P2266 to Annex D is more
realistic (and actually broke a libstdc++ test):
X& foo(X&& x) { return x; }
> + }
> +</code></pre>
> +
> </body>
> </html>
>
