On Fri, Aug 24, 2018 at 12:53 AM, Marek Polacek <pola...@redhat.com> wrote:
> On Thu, Aug 23, 2018 at 10:44:30AM -0400, Marek Polacek wrote:
>> +T
>> +fn3 (const T t)
>> +{
>> + // t is const: will decay into move.
>> + return t;
>> +}
>> +
>> +T
>> +fn4 (const T t)
>> +{
>> + // t is const: will decay into move despite std::move, so it's redundant.
>> + return std::move (t); // { dg-warning "redundant move in return
>> statement" }
>> +}
>
> This should read "decay into copy". We can't move from a const object.
> Consider
> it fixed.
Well, we'll do the overload resolution as though t were an rvalue,
even though it's const; it's just unlikely to succeed, since a
constructor taking a const rvalue reference doesn't make much sense.
It occurs to me that the std::move might not be redundant in some
cases: for the implicit treatment as an rvalue, the return must select
a constructor that takes an rvalue reference to the returned object's
type. With an explict std::move, that restriction doesn't apply. So,
for
struct C { };
struct A {
operator C() &;
operator C() &&;
};
C f(A a)
{
return a; // calls operator C()&
return std::move(a); // calls operator C()&&
}
...though I see we currently get the first return wrong, and call the
rvalue overload for both. I think there was a recent core issue in
this area, I'll try to find that later.
Anyway, I imagine this sort of example is rare enough that the warning
is still worth having; people doing this can use static_cast instead
or just turn off the warning.
BTW, Instead of using location_of (retval) in each diagnostic call,
let's put at the top of the function
location_t loc = cp_expr_loc_or_loc (retval, input_location);
and use 'loc' in the diagnostics. This is the pattern I generally mean to use.
Jason
