[libcxx-commits] [PATCH] D93383: [libc++] Use c++20 instead of c++2a consistently.

Wed Dec 30 07:24:33 PST 2020

Quuxplusone added inline comments.

================
Comment at: libcxx/include/__config:56
+#    define _LIBCPP_STD_VER 21  // current year, or date of c++2b ratification
 #  endif
 #endif  // _LIBCPP_STD_VER
----------------
curdeius wrote:
> Quuxplusone wrote:
> > My understanding is that you're planning to make other changes in a separate PR to finish up adding a c++2b mode for real. And I like this patch and don't want to slow it down. But I echo what @miscco said: shouldn't you just go all the way to c++2b in //this// patch? Is there really a good reason to land this intermediate state rather than go all the way to c++2b in one hop?
> The only reason I have is that this patch doesn't need a compiler with -std=c++2b support, whereas adding C++2b does need one.
> I don't mind adding C++2b here, but I'll need to wait for D93520 to land first to do it.
I hope/guess you mean that the new codepaths would be //exercised// only on compilers with 2b modes, right? (Not that the patch would suddenly //require// everyone's compiler to have a 2b mode?)

Clang trunk apparently already supports a 2b mode: https://godbolt.org/z/T3EjT3
so by adding C++2b here and landing it, you'd be letting people run libcxx tests //locally// in 2b mode, even though buildkite won't run them in that mode yet. Right?

Anyway, assuming all my assumptions are correct, my opinions are unchanged: I think it'd be nice to jump from 2a to 20+2b in one hop, but I think it's most important to not hold up this PR. (Which at the moment is waiting for the relevant people to get back from holiday break — or so I'm guessing from patterns of Phab activity lately. :))

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93383