aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
diff options
context:
space:
mode:
authorNikolas Klauser <nikolasklauser@berlin.de>2024-03-09 01:09:28 +0100
committerGitHub <noreply@github.com>2024-03-09 01:09:28 +0100
commit4d323e404d43526ad8263769f00aace9db2e57c5 (patch)
treea8c4627b72e63557078ba961668ea863c7a38b49 /clang/lib/CodeGen/CodeGenFunction.cpp
parent624ea68cbc3ce422b3ee110c0c0af839eec2e278 (diff)
downloadllvm-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