diff options
author | Nikolas Klauser <nikolasklauser@berlin.de> | 2024-03-09 01:09:28 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-03-09 01:09:28 +0100 |
commit | 4d323e404d43526ad8263769f00aace9db2e57c5 (patch) | |
tree | a8c4627b72e63557078ba961668ea863c7a38b49 /clang/lib/CodeGen/CodeGenFunction.cpp | |
parent | 624ea68cbc3ce422b3ee110c0c0af839eec2e278 (diff) | |
download | llvm-4d323e404d43526ad8263769f00aace9db2e57c5.zip llvm-4d323e404d43526ad8263769f00aace9db2e57c5.tar.gz llvm-4d323e404d43526ad8263769f00aace9db2e57c5.tar.bz2 |
[libc++] Allow the use of extensions in the implementation (#79532)
We've talked about allowing extensions on
[discourse](https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/5)
and in a libc++ monthly meeting and agreed to test it out in the LLVM 18
release. We've done that with the `tuple` constructor overload set
(using conditional `explicit`). Since we haven't heard about any
breakages, it seems safe to do. This patch enables the use of extension
from later C++ standards inside the versioned `std` namespaces. This
should be good enough, since almost all of our code is inside that
namespace. This approach also avoids the use of extensions inside the
test `std` suite. That part of the code base should stay clean, since
it's a test suite that is also used by other vendors to test their
implementations.
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions