[cfe-dev] Q on patch for CWG 2352

[Robinson, Paul via cfe-dev]

> +Hans for 10.0 visibility.

The new (corrected) behavior is in 10.0, there is nothing to fix here.  Arguably there could be a release note.
--paulr

From: Shoaib Meenai <smeenai at fb.com>
Sent: Friday, March 6, 2020 7:35 PM
To: richard at metafoo.co.uk; Robinson, Paul <paul.robinson at sony.com>
Cc: David Blaikie <dblaikie at gmail.com>; cfe-dev at lists.llvm.org; Hans Wennborg <hans at chromium.org>
Subject: Re: [cfe-dev] Q on patch for CWG 2352

+Hans for 10.0 visibility.

From: Richard Smith <richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>>
Reply-To: "richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>" <richard at metafoo.co.uk<mailto:richard at metafoo.co.uk>>
Date: Friday, March 6, 2020 at 4:28 PM
To: "Robinson, Paul" <paul.robinson at sony.com<mailto:paul.robinson at sony.com>>
Cc: Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>>, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>>, cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] Q on patch for CWG 2352

On Thu, 5 Mar 2020 at 11:41, Robinson, Paul via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
> Richard Smith made a patch in f041e9ad for CWG2352.
> As a consequence of this patch, we had an obscure test failure,
> and it's not clear to me that it's an intentional consequence.
> So I figured I'd ask here.
>
> Reduced test case:

Slightly edited and expanded test case:

bool foo(void * const * const *       &&) { return false; } // new choice
bool foo(void *       * const * const &)  { return true; }  // old choice
bool bar() {
 return foo(reinterpret_cast<void***>(2));
}

I'm not entirely sure how we were coming up with the old answer, but the new answer is correct: binding an rvalue reference to an rvalue is preferred over binding an lvalue reference.

// A couple of additional cases:
void*** p;
void*** q() { return p; }
bool func1() { return foo(p); } // old and new both call '&' overload
bool func2() { return foo(q()); } // old calls '&', new calls '&&'

Here, q() is an rvalue, so we prefer binding an rvalue reference. p is an lvalue, so that rule doesn't apply and we prefer binding the lvalue reference because it binds to a less-qualified type.

I believe the new Clang behavior is following the rules described in C++ [over.ics.rank] paragraph 3.

So it looks like it matters whether the argument is an expression?
--paulr


> Prior to the patch, the compiler selected the second overload;
> after the patch, it selects the first overload.  Apparently there's
> some subtle difference in the preferred-ness of one over the other,
> and AFAICT the const-nesses aren't supposed to factor in any more?
> so it's about the &-ref versus the &&-ref?
>
> As I said, mainly I want to make sure this was intentional; if it
> is, we can fiddle our test and that's the end of it.  But if it's
> not intentional, this change is in the almost-final Clang 10.0
> release, and might want to be fixed before it goes out.
>
> Thanks,
> --paulr
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ypmPfXfKC2Dzmek68WWseeMwGZvv18RMduMOIPY1Plc&s=872P1W35_a99gl6FhfNvVJzNWhiLZIs8FwP9QyWcbsM&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200309/5d46ade0/attachment-0001.html>