It seems likely that we will raise the toolchain version requirements later this week or beginning of next one. This message is a heads up for the buildbot owners and other people that build LLVM directly from main to make preparations for this migration.
The new requirements are as follows:
Apple Clang 9.3
Visual Studio 2019 16.7 (This is already the requirement in main)
The current time-plan looks like this:
Let the diff be reviewed and discussed during this week 4/4 - 8/4
The soft error will land in main after this.
This soft error will then live in main until LLVM 15 has been branched
Hard error will be landed in main after the branch
CXX_VERSION will be changed to C+17 and developers are allowed to use C++17 in main.
LLVM 16.x will be the first version hard requiring these changes.
Please keep comments about this change to the phabricator review or the first forum post. This one is mainly used as an announcement thread where I will update the status as we go along.
FYI - we ran into an issue trying to sequence a CXX_STANDARD upgrade to 17 (one of our deps started landing code that required it) and hit a sharp edge in both CMake and GCC. Workaround here: https://github.com/iree-org/iree/pull/9924 (I expect anyone who is consuming LLVM and becomes mis-aligned on the standard version may hit this as soon as they integrate the patch bumping it). Iiuc, there are some CMake policies in play that affect how normal variables shadow later defined cache variables and in some combination can cause LLVM’s cache variable to take precedence over a setting at a higher level.
In our case, it was causing a multiple definition error on a static constexpr int at class scope within MLIR. tl;dr - if you start getting multiple definition errors on GCC after this switch and are using LLVM as a library, double check that the CXX_STANDARD settings are being applied identically to both the code including LLVM headers and LLVM itself (which due to CMake issues can become mis-aligned easily).
It looks like the toolchain shipped as Apple Clang 9.3 doesn’t have full support for C++17 features, particularly std::variant and std::optional (see Compiler support for C++17 - cppreference.com, it claims support for those comes with 10.0.0).
ATM, LLVM already accumulated usage of std::variant in its various components (TableGen, DenseMap, CodeGen, flang, pseudo, MLIR) as none of the buildbots seem to be testing this configuration.
I think the extent of my investigation here was to check which Apple Clang version matched the Clang version we were bumping to. But I am no expert on Apple Clang and no one objected back then when the exact versions were discussed.
I think it makes sense to bump it to 10.0.0, but I think you should create a separate RFC for that and make sure that no one that actually knows the apple clang versions and usage disagrees. I think it’s better if we try to do this before we branch to LLVM 16 so that we don’t bump toolchain requirements in two subsequent versions of LLVM.
@tschuett would you be OK with proposing that RFC? I am more than happy to send a draft, but I don’t really have the means to test or understand the issues that might come up without spending a significant amount of time.