rsmith 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
----------------
ldionne wrote:
> 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?
Install paths are set in `libcxx/include/CMakeLists.txt` for the headers and in 
`libcxx/src/CMakeLists.txt` for the libraries (search for `install(`) based on 
cmake variables LIBCXX_INSTALL_HEADER_PREFIX, LIBCXX_INSTALL_PREFIX, and 
LIBCXX_INSTALL_LIBRARY_DIR.

It would probably make sense to put the libc++ headers into somewhere like 
`/usr/lib/clang/$VER/include/c++` instead of directly in 
`/usr/lib/clang/$VER/include`; that'll need some changes to the clang driver to 
make sure we look there. But of course that's doable if the two are 
version-locked :)


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

Reply via email to