[RFC] Upgrading C++ std from 17 to 20 in flang

[bob.belcher]

Hello,

Since it is allowed to use different C++ std versions on the subproject level, and since at least one other subproject uses C++20 already, I was wondering if there is any interest to upgrade to C++20 in flang as well?

Background

The initiating motivation for this proposal is this PR where using member designators would make the code a bit cleaner. Of course, there might be other places where C++20 niceties can be also used.

[Endill]

A relevant thread:

[RFC] Clang 17.0.6 would be minimum version to build LLVM in C++20

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.

[kparzysz]

That’s a big move. I’m not sure if you can specify a different compiler for a subproject, if not then the entire project would have to use a compiler that supports C++20.

That other subproject is a libc++ test, so it’s not a functional component of the project.

[clementval]

I would not make the move unless MLIR moves as well.

[efriedma-quic]

I would discourage flang from moving the required language version before LLVM. flang started using C++17 “early”, but that wasn’t really an issue because it was still experimental at the time. Now, flang is a more mature project, and people are starting to integrate it into their builds and distribute it. Since LLVM doesn’t bootstrap by default, that means flang is getting built with the host compiler, so imposing stricter compiler requirements is likely to cause issues for users.

If we did bootstrap by default, maybe we could draw a line between “bootstrap components” and “non-bootstrap components”, and skip building flang in the first stage, but I haven’t seen anyone propose anything like that.

libc++ is sort of in a different space: a new C++ compiler is necessary to support new C++ library features. And because it’s a runtime, it’s less of a burden to build an appropriate compiler for it; for example, LLVM_ENABLE_RUNTIMES does this automatically.

[mehdi_amini]

@bob.belcher

Since it is allowed to use different C++ std versions on the subproject level

I’m not sure that we intend to have subprojects define their own version in general: IMO this should be an “exceptional” thing with careful consideration: like when Flang was merged in the repo and was already on c++17, we accepted a divergence until LLVM catches up (if I remember correctly).

@bob.belcher

since at least one other subproject uses C++20 already

I wouldn’t call this a subproject: seems like a small tool that is part of the tests of libc++ apparently. It’s not causing any requirement on building a toolchain I assume.

[bob.belcher]

Thanks all for the educating arguments! I am now a bit less naive than yesterday .