[PATCH] D104500: [clang] Apply P1825 as Defect Report from C++11 up to C++20.
James Y Knight via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 7 15:57:48 PDT 2021
jyknight added a comment.
This commit seems to have broken libc++ in C++98 mode, as it appears to have depended upon the implicit-move extension.
Reproduction is simple. Build this with `-stdlib=libc++ -std=c++98`:
#include <set>
void foo (std::set<int> *s) {
s->insert(5);
}
(https://godbolt.org/z/vKWKhE34x)
The root cause appears to be that libc++ emulates unique_ptr in c++98 mode, and this emulation stopped working. E.g. this no longer works (compiled with same flags):
#include <memory>
std::unique_ptr<int> foo() {
std::unique_ptr<int> x;
return x;
}
To simplify further, removing the stdlib headers: returning a type with a move constructor but no copy constructor used to work, and now doesn't (with -std=c++98).
struct uncopyable {
uncopyable() = default;
uncopyable(uncopyable const&) = delete;
uncopyable(uncopyable&&) = default;
};
uncopyable bar() {
uncopyable x;
return x;
}
Now, of course, the above is invalid c++98, because rvalue references aren't even a thing there...but clang _does_ implement rvalue references in c++98 mode, and libc++ depends on it.
So -- I think either libc++ needs to stop depending on this nonstandard functionality, or we need to keep implementing it in Clang. I don't know which option would be more desirable.
CC+=ldionne, for libc++ expertise.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104500/new/
https://reviews.llvm.org/D104500
More information about the cfe-commits
mailing list