RFC: Bump minimal requirements Apple Clang 9.3 -> 10.0.0 before 4th Tue in January

Apple Clangs are awesome. During the
bump to support C++17 in LLVM the requirements for Apple Clangs were bumped to 9.3. Apple Clang 10.0 is even better.

Apple Clang 9.3 Apple Clang 10.0
std::any X
std::optional X
std::string_view X
std::variant X

Apple Clang 10.0.0 would facilitate us to get rid of all the unions and eventually migrate from the LLVM optional to the std one.

Even worse there is already std::variant in the codebase. This was not catched by the buildbots.

The developer policy for
updating toolchains is a long process.

The actual bump was short.

Do we need to go through the whole process?

Is there a fast path for small adjustments?

Our current requirement Xcode/Apple Clang 9.3 was released in March 2018, 10.0.0 was released September 2018 - which is in line with the other toolchains we require. The Spreadsheet I used for this the last time is here: LLVM Toolchain Support Matrix - Google Sheets

I support bumping this to 10.0.0 as part of the bumps we are doing in LLVM 16.x anyway, but I am not an apple clang / xcode expert. So feel free to push back on that if you think we need more time to integrate this upgrade.

I am more interested in the fast path. Can we make this happen within 30 days?

I should think that depends primarily on the state of the Apple bots, making sure they are all at the minimum or higher.

In practice, I doubt anyone running something older than Apple Clang 10 is able to build a recent release of LLVM. Users with older versions of Apple Clang are most likely on High Sierra or older, but you need Mojave or newer. See

Of course, you could be on Mojave but running an older version of Xcode, but that seems atypical.

It really bothers me that there is std::variant in the codebase and no Buildbot catched that misbevior.

It turns out, this would actually be a no-op change.
Here are some findings we’ve found with @sam-mccall while digging deeper at it.

In theory XCode 9.3 comes with a clang that prints 9.1.0 in its version string [1], but our toolchain requirements check for 9.3.0.
Looking at the same table, the next version of apple clang string that’s available is 10.0.0. Hence 9.3.0 doesn’t exist, and our soft error has already been enforcing people to install at least apple clang 10.0.0 (or XCode 10.0).

So previous version bump actually bumped the requirement to apple clang 10.0.0 effectively. Hence changing the documentation and cmake files to mention 10.0.0 should just be an RFC. Therefore I’d suggest treating this as a “typo in the documentation” rather than waiting for some release cycles.

that’s a separate concern that should be addressed, but probably on a different thread. today we have apple buildbots that are ran at Clang Stage 1: cmake, RA, using system compiler #31639 Console [Jenkins] and all of them seem to be using apple clang 12.0.0

Yes, we should make sure that we have buildbots that compile with our lowest version required ideally.

In that case I am 100% fine with this change.

in that case, i took the liberty of sending out ⚙ D136609 [llvm] Fix minimum Apple Clang requirement

+1 this has been a gap in our bot coverage forever. The problem is finding someone willing to provide the resources (three bots: clang linux, gcc linux, and msvc windows, all with the necessary minimum versions).

For the record - not just in theory! I installed the “Command Line Tools (macOS 10.13) for Xcode 9.3” on a machine running 10.14.6, and:

  • clang --version reports 9.1.0
  • building LLVM fails (hits the cmake version check and says I need clang 9.3)

So Xcode 9.3 has definitely been broken since the requirement was bumped, and was a soft error before that.

+1 to fixing this in the docs as a DR.

Kudos for finding the root cause!!!