[PATCH] D104500: [clang] Apply P1825 as Defect Report from C++11 up to C++20.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D104500#2865917 <https://reviews.llvm.org/D104500#2865917>, @mizvekov wrote:

> In D104500#2865849 <https://reviews.llvm.org/D104500#2865849>, @Quuxplusone wrote:
>
>> @mizvekov, I don't understand what you mean by "yet another" mechanism. This is just asking to restore Clang's C++98/03 extension (that supports move constructors even in C++03). It's asking to //remove// special-case code you added, right? Find the line where you're saying "oh but if it's C++03 then //don't// do the usual rvalue lookup," and remove that.
>>
>> My naive guess is line 3459:
>>
>>   if (getLangOpts().CPlusPlus11 && !getLangOpts().CPlusPlus2b &&
>>       NRInfo.isMoveEligible()) {
>>
>> should maybe be just
>>
>>   if (!getLangOpts().CPlusPlus2b && NRInfo.isMoveEligible()) {
>>
>> Could you look into that?
>
> With that change, you get the full P1825 <https://reviews.llvm.org/P1825> implicit move in C++98, which modifies the semantics of pure C++98 programs.
> Like I said in the commit message, this can change which copy constructor is picked, between non-const and const ones.
>
> To continue supporting C++98, we would need to keep the old C++11 implicit move code around.
>
>>> And I think libc++ is in the process of ditching support for C++98 completely, though I might be mistaken about the extent here.
>>
>> Nope, untrue. I've been making some patches to ditch libc++'s `_LIBCPP_CXX03_LANG` macro, but I'm doing that precisely because the only compiler we support in C++03 mode is Clang, and on Clang we //can// actually use rvalue references and variadic templates and so on, even in C++03 mode. That is, this extension (that was broken by this patch) is actually //the only reason libc++ works in C++03 mode at all!// So it's important to preserve the extension. (And presumably there might be clients relying on the extension, besides just libc++.)
>
> Well I thought that meant exactly that libc++ does not support C++98, it only works on clang because it provides so much of C++11 as an extension.
>
> I did not remove this just on my own whim by the way, the information I had and the reason the patch was approved as is, is because as I said, those extensions were considered best effort and not officially supported.
> @rsmith thoughts?

I wonder if we can restore the extension behavior for the types that want it, while still using the C++98 rules for the rest of the cases? Perhaps we could use the new C++11-to-C++20 logic even in C++98 if the return type declares a move constructor?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104500/new/

https://reviews.llvm.org/D104500