After PR-72348, the minimum clang version to build LLVM trunk in C++20 mode would be clang 17.0.6.
If you do not build LLVM in C++20, this change does not effect you.
If you build LLVM trunk in C++20, you would need to upgrade clang to the 17.0.6 release.
Please reach out if you find this concerning.
My primary concern is whether that’s too big of a jump from Clang 5.0 (current documented min, circa 2017) to 17 (late 2023) and whether that will prevent people from building with C++20 once we get to the point we want to start allowing C++20 features into the code base. However, some upgrade is certainly necessary for that and 17 is better than previous releases in terms of C++20 support, so I think this is probably reasonable.
I’m a bit concerned about this because my employer (who I’m not speaking for) needs to ship binaries for older Linux releases. This entails building Clang on a very old Linux distribution with a (semi-manually) upgraded toolchain. We’ve gotten Clang 11.1 to work in this environment but getting past that will be pushing our luck.
Am I correct in reading this as meaning I will still be able to build LLVM and Clang with the older toolchain and have all of the features it provides so long as I do not run the compiler with -std=c++20 set?
That’s correct, these changes should only impact building LLVM and Clang with -std=c++20.
To clarify further, this change should not affect most users. I don’t think we are ready to migrate LLVM’s minimum C++ language version from C++17 to C++20.
Raising the language version usually requires auditing the support level of our various supported toolchains, and making sure the versions we need are widely available in the right contexts.
The announced change effectively resets the clock for platforms where Clang is the supported C++ compiler. We will have to wait until the changes in 17.0.6 have been released through XCode before we can require C++20 to build the project. My understanding of Aaron’s concern is that this will either delay our future adoption of C++20, or cause us to drastically increase our minimum toolchain support requirements at that time (2017 → 2023).
Not sure if I understood you correctly, but the current requirements where implemented recently in our move to C++17 here: https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm
I think you are right in your claim though. Say we gate building LLVM in C++20 mode we can’t make C++20 the default for a VERY long time.
Is there a specific C++20 feature that requires clang 17?
OP cited a bugfix in 17.0.6 that would be needed to build LLVM in C++20 mode. Since that just happened, our normal “support build compilers up to 3 years old” guideline means we’d have to wait 3 years to update LLVM’s minimum dialect to C++20. Of course that’s a guideline, not a requirement, but it’s there for a reason.
Is there a specific C++20 feature that requires clang 17?
Until Clang 17, support for C++20 was extremely buggy. I would not recommend that anyone use previous versions in C++20 mode – it’s just not worth the problems.
There were multiple serious issues for consteval, concepts, and other new features. For Google’s internal codebase, these caused problems just trying to switch from -std=c++17 to -std=c++20 – including silent miscompiles. Our codebase didn’t even use C++20 features, we were just switching the compilation mode (which introduced usage of C++20 features via the stdlib headers.)
For reasonable C++20 compiler support, I’ve been making a recommendation of the following minimum compiler versions:
…and don’t use coroutines or modules yet, both of which are not yet fully-baked.
So, this proposal would really only raise the realistic minimum for building LLVM in C++20 mode from “17.0.0” to “17.0.6”.
Just a nit: it’s not “up to 3 years old”, it’s “the last 3 years at a minimum” 
The exact wording is:
It is a general goal to support LLVM and GCC versions from the last 3 years at a minimum.
In general we support a much longer timeframe and upgrade based on being able to use new features of the language.
(that said, I don’t know who else than Apple has a strong dependency on the clang version, maybe FreeBSD has clang as default compiler and would be the main one to look for?).
In general we support a much longer timeframe and upgrade based on being able to use new features of the language.
(that said, I don’t know who else than Apple has a strong dependency on the clang version, maybe FreeBSD has clang as default compiler and would be the main one to look for?).
Other than FreeBSD, OpenBSD. We’re just in the midst of upgrading to 16. FreeBSD upgraded to 16 about 6 months ago and backported to 14.0 -release / 13 -stable. For -current FreeBSD tends to go release to release for LLVM / Clang. OpenBSD tends to go 2 - 3 releases at a time due to the work and overhead. We just went 13 to 16. I can’t see anyone wanting to rush to update to 18 after finishing this. So ya, easily 2 years away for an update to 19.
@DimitryAndric can speak more concretely about FreeBSD’s base system clang, but I believe he’s planning to upgrade our main branch to 17 fairly soon and that 14.1 will likely ship with 17 or 18.
In general, our latest release from the newest release branch is going to be no more than 18 months behind and that’s the only thing we guarantee will be able to build main (we do try to keep it building from all release branches, but in a pinch requiring a package to be installed would be acceptable for older releases.)
A bigger practical constraint for us is probably that right now we try to keep FreeBSD building with the most recent two Ubuntu LTS releases (20.04 currently has Clang 12 which we’ll drop support for after 24.04 comes out). I suspect that means that we’d want 26.04 to be out before an LLVM release that absolutely required C++20, but that’s quite a ways in the future and things could change are requirements in the meantime.
I guess I got the comparison operator backwards! 
Yes, FreeBSD’s main branch will go to llvm 17 soon (I hope ), so FreeBSD 14.1 is expected to ship with at least llvm 17. I will most likely also merge llvm 17 to FreeBSD 13.x, so it should end up in 13.3 at some point. (Older FreeBSD branches will be EOLd very soon, so they no longer really count.)
So, this proposal would really only raise the realistic minimum for building LLVM in C++20 mode from “17.0.0” to “17.0.6”.
I agree.
My understanding of Aaron’s concern is that this will either delay our future adoption of C++20, or cause us to drastically increase our minimum toolchain support requirements at that time (2017 → 2023).
This captures my concern nicely, but I think for all practical purposes, there’s not much to be done about it because Clang 17.0.0 really would be a bare minimum compiler for C++20 support. I thought we already documented that we required the latest patch level as well, but I’m not spotting those docs so I could be wrong. Regardless, expecting users to have the later patch seems reasonable to me.
I’m not seeing anyone opposed to this RFC. If that’s not correct, please speak up in the next two weeks, otherwise I think this RFC is accepted at that point. (This gives folks ~3 weeks to weigh in on the RFC in case folks were out for vacation. I don’t see a reason to delay until after the holidays to move forward – if this is disruptive, we’ll still have time to make a different decision before the Clang 18 branch.)
I support this proposal, when CMAKE_CXX_STANDARD=20, we impose higher compiler version requirement.
Has anyone tested GCC 12 or MSVC 17.2?
Update: since there had been no more issues raised here, we have upgraded the C++20 buildbot to Clang 17.0.6.
I have also ran GCC 12 and hit only 1 small issue, otherwise it works and passes check-clang and check-clang-tools.
I will look into adding a buildbot with GCC 12 to make sure it keeps working. It’s harder for me to test MSVC, it would definitely be nice if someone would check it.