Proposal: Upgrade C++ compiler feature level to C++ 17

[huoyaoyuan]

The coreclr codebase has been using C++ 11 for a long time. Adopting C++ 17 features can help simplifying some code, for example message-less static_assert, or usage of filesystem in non-clr testing code.

It would require all supported configurations to have C++ 17 compatible compiler. Since we have upgraded the CMake requirement to 3.20 which was released in March 2021, it's unlikely to see an environment to have CMake 3.20 but no C++ 17 compiler.

On Windows and Apple OSes we are using latest compilers so there should be less concern. According to https://en.cppreference.com/w/cpp/compiler_support/17 , all C++ 17 language features are supported since GCC 7. RHEL 8 includes GCC 8.x. I couldn't figure out the GCC version included in all distros, but it seems that all our supported distros are having higher GCC version.

/cc @jkoritzinsky @dotnet/distro-maintainers Any comment or blocker on this?

[jkoritzinsky]

We are also limited by the features of the target rootfs's stdlib, which may be quite out of date (I'm not sure the feature set of the libstdc++ in Ubuntu 18.04). Although given our current guidance, that does only matter for testing code since we recommend against heavy STL usage in product code.

[EgorBo]

Adopting C++ 17 features can help simplifying some code, for example message-less static_assert, or usage of filesystem in non-clr testing code.

Is there anything else we'd benefit from? I think the proposal should include a strong motivation "why"

[huoyaoyuan]

I think the proposal should include a strong motivation "why"

The major benefit should be code simplification, plus some opportunity for taking compiler optimization. I was initially initiated by checking static_assert. I'll try to summarize more cases.

[dviererbe]

In Ubuntu we use Clang to compile .NET. We (Canonical) only build for Ubuntu 22.04+, but Microsoft supports and builds also for Ubuntu 18.04+.

According to https://clang.llvm.org/cxx_status.html:

Clang 5 and later implement all the features of the ISO C++ 2017 standard.

Ubuntu has the following Clang versions (5+):

Ubuntu version	available LLVM/Clang versions
18.04 LST (Bionic Beaver)	5, 6 (default), 7, 8, 9, 10
20.04 LTS (Focal Fossa)	6, 7, 8, 9, 10 (default), 11, 12, 18
22.04 LTS (Jammy Jellyfish)	11, 12, 13, 14 (default), 15
24.04 LTS (Noble Numbat)	14, 15, 16, 17, 18 (default), 19
24.10 (Oracular Oriole)	14, 15, 16, 17, 18, 19 (default)
25.04 (Plucky Puffin)	14, 15, 17, 18, 19 (current default), 20 (planned default)

See:

• https://launchpad.net/ubuntu/+source/llvm-defaults
• https://launchpad.net/ubuntu/+source/llvm-toolchain-20
• https://launchpad.net/ubuntu/+source/llvm-toolchain-19
• https://launchpad.net/ubuntu/+source/llvm-toolchain-18
• https://launchpad.net/ubuntu/+source/llvm-toolchain-17
• https://launchpad.net/ubuntu/+source/llvm-toolchain-16
• https://launchpad.net/ubuntu/+source/llvm-toolchain-15
• https://launchpad.net/ubuntu/+source/llvm-toolchain-14
• https://launchpad.net/ubuntu/+source/llvm-toolchain-13
• https://launchpad.net/ubuntu/+source/llvm-toolchain-12
• https://launchpad.net/ubuntu/+source/llvm-toolchain-11
• https://launchpad.net/ubuntu/+source/llvm-toolchain-10
• https://launchpad.net/ubuntu/+source/llvm-toolchain-9
• https://launchpad.net/ubuntu/+source/llvm-toolchain-8
• https://launchpad.net/ubuntu/+source/llvm-toolchain-7
• https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0
• https://launchpad.net/ubuntu/+source/llvm-toolchain-5.0

TL;DR: Therefore, upgrading the C++ compiler feature level to C++ 17 should not be an issue for the Ubuntu platform.

[omajid]

RHEL / CentOS Stream

On RHEL (and CentOS Stream) we also use clang to build .NET. Here are the default versions of clang in each:

RHEL/CentOS Stream version	Clang versions
RHEL 8	18
RHEL 9	18
CentOS Stream 10	19

These are new enough that they should support everything .NET needs from C++ 17

Fedora

Fedora version	Clang versions
Fedora 40	18
Fedora 41	19
Fedora 42	19
Fedora Rawhide	19

These are new enough that they should support everything .NET needs from C++ 17

[AaronRobinsonMSFT]

I personally don't see any reason not to move forward in this case.

The major benefit should be code simplification, plus some opportunity for taking compiler optimization. I was initially initiated by checking static_assert. I'll try to summarize more cases.

We should be careful here. The C++ in this code base should be simple. We're not looking to adopt most modern C++ features. There are some APIs that we could benefit from, but they are narrow in scope. An example of a beneficial win from keeping more current would be adoption of the gsl libraries, it only requires C++ 14 which we use in some cases already.

Specific benefits from C++17 itself are things like the fallthrough attribute or some narrow uses of constexpr. Features that we'd likely prefer to avoid are things like std::string_view, __has_include, nested namespaces or the new filesystem APIs.

Keeping as current as possible is a good goal, but it should be in service of staying current and modern rather than grabbing newer C++ features. This is a just a priority thing.

[janvorli]

I've just bumped into a case today that would benefit from moving to C++17 too. The if constexpr (condition) in template methods / classes would be useful in my case to make some calls in a template method optional for specific template argument types. There is a way do achieve the same thing in a different way, but the constexpr one would be nice and clean.