[libcxx-commits] [PATCH] D93383: [libc++] Use c++20 instead of c++2a consistently.
Arthur O'Dwyer via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
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 // _LIBCPP_STD_VER
> 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. :))
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the libcxx-commits