ldionne added inline comments.
================ Comment at: libcxx/include/version:254 // # define __cpp_lib_concepts 201806L +# define __cpp_lib_constexpr_dynamic_alloc 201907L // # define __cpp_lib_constexpr_misc 201811L ---------------- rsmith wrote: > ldionne wrote: > > rsmith wrote: > > > Should this be conditioned on compiler support being available? > > So.. I've decided not to do that in this patch so far. > > > > The support for constexpr allocation was checked into Clang about a year > > ago, right? I actually expect this to be a slightly contentious point, but > > I'd like to assume that we're using a reasonably recent Clang. I don't see > > a strong point for being able to use new libc++ headers with an old Clang > > anyway, since vendors usually release the two together. IOW, supporting > > this would add complexity for virtually no benefit. I do agree it's a > > slightly more aggressive stance than we've had so far, but this sort of > > reasonable assumption makes it so much easier to write stuff for libc++. > OK, just a few thoughts then I'm going to bow out of this; this seems like a > policy decision for the libc++ maintainers to make. > > In favor of dropping support for new libc++ + old clang: we generally don't > permit version skew between different components of LLVM. It seems reasonable > to expect all wanted parts of a particular LLVM release to be built together. > > Against dropping support for new libc++ + old clang: we do support installing > more than one version of LLVM (and in particular more than one version of > Clang) on the same system, but because libc++ defaults to being installed in > `/usr/include/c++/v1`, we don't seem to encourage installing more than one > version of libc++, so -- even assuming we only support the *newest* version > of libc++ going into `/usr/include/c++/v1` -- new versions of libc++ need to > work with old versions of Clang. > > I think (largely by accident) Clang will prefer a libc++ installed into > `/usr/lib/clang/$VER/include` over one from `/usr/include/c++/v1`. If we > switched to installing libc++ there, I don't see any technical barrier to > version-locking them, though I'm not sure what story that leaves for use of > libc++ with GCC and other compilers. It seems worth noting that this is > exactly what libstdc++ does in order to need to support only one version of > GCC. > OK, just a few thoughts then I'm going to bow out of this; this seems like a > policy decision for the libc++ maintainers to make. Hear hear! > I think (largely by accident) Clang will prefer a libc++ installed into > `/usr/lib/clang/$VER/include` over one from `/usr/include/c++/v1`. If we > switched to installing libc++ there, I don't see any technical barrier to > version-locking them, though I'm not sure what story that leaves for use of > libc++ with GCC and other compilers. It seems worth noting that this is > exactly what libstdc++ does in order to need to support only one version of > GCC. I think it would be great to do that. Honestly, this is a huge simplification and makes implementing new features much easier. Also, I think it's reasonable to support not-trunk compilers, like 6 months old or something like that. But not several years back. One last question: do you know what controls where the libc++ headers are installed as part of the LLVM distribution? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68364/new/ https://reviews.llvm.org/D68364 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
