[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