tree 2b1a25f927aabbede8a2ef7bf0872a9669052d71
parent 799a23cf0602b9ab75a5c591db63382ac0d392e1
author Mike Klein <mtklein@google.com> 1582054403 -0600
committer Skia Commit-Bot <skia-commit-bot@chromium.org> 1582070135 +0000

turn on -Wreturn-std-move-in-c++11

This CL has a complicated back story, but it's concrete change is
simple, just turning the warning on and converting a bunch of

    return foo;

to

    return std::move(foo);

These changes are exclusively in places where RVO and NRVO do not apply,
so it should not conflict with warnings like -Wpessimizing-move.

Since C++11, when you return a named local and its type doesn't match
the declared return type exactly, there's an implicit std::move()
wrapped around the value (what I'm making explicit here) so the move
constructor gets an opportunity to take precedence over the copy
constructor.  You can read about this implicit move here under the
section "automatic move from local variables and parameters":
https://en.cppreference.com/w/cpp/language/return#Notes.

This situation comes up for us with smart pointers: a function declares
its return type as std::unique_ptr<Base> or sk_sp<Base>, and we return a
std::unique_ptr<Impl> or sk_sp<Impl>.  Those types don't match exactly,
so RVO and NRVO don't come into play.  They've always been going through
move constructors, and that's not changed here, just made explicit.

There was apparently once a bug in the C++11 standard and compilers
implementing that which made these copy instead of move, and then this
sort of code would do a little unnecessary ref/unref dance for sk_sp,
and would entirely fail to compile for uncopyable std::unique_ptr.
These explicit moves ostensibly will make our code more compatible with
those older compilers.

That compatibility alone is, I think, a terrible reason to land this CL.
Like, actively bad.  But... to balance that out, I think the explicit
std::move()s here actually help remind us that RVO/NRVO are not in play,
and remind us we're going to call the move constructor.  So that C++11
standard bug becomes kind of useful for us, in that Clang added this
warning to catch it, and its fix improves readability.

So really read this all as, "warn about implicit std::move() on return".
In the end I think it's just about readability.  I don't really hold any
hope out that we'll become compatible with those older compilers.

Bug: skia:9909
Change-Id: Id596e9261188b6f10e759906af6c95fe303f6ffe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271601
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>