[cfe-dev] Q on patch for CWG 2352
Shoaib Meenai via cfe-dev
cfe-dev at lists.llvm.org
Mon Mar 9 09:54:33 PDT 2020
Right. I was just bringing Richard's reply to Hans' attention, to make sure he saw that the new behavior was correct and there were no concerns here for the 10.0 release.
________________________________
From: Robinson, Paul <paul.robinson at sony.com>
Sent: Monday, March 9, 2020 5:38:45 AM
To: Shoaib Meenai <smeenai at fb.com>; richard at metafoo.co.uk <richard at metafoo.co.uk>
Cc: David Blaikie <dblaikie at gmail.com>; cfe-dev at lists.llvm.org <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.
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=>
________________________________
From: Robinson, Paul <paul.robinson at sony.com>
Sent: Monday, March 9, 2020 5:38:45 AM
To: Shoaib Meenai <smeenai at fb.com>; richard at metafoo.co.uk <richard at metafoo.co.uk>
Cc: David Blaikie <dblaikie at gmail.com>; cfe-dev at lists.llvm.org <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.
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/498f634a/attachment-0001.html>
More information about the cfe-dev
mailing list