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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
