Repository navigation
Proposal: Upgrade C++ compiler feature level to C++ 17 #112419
Description
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?
Activity
jkoritzinsky commentedon Feb 11, 2025
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 commentedon Feb 12, 2025
Is there anything else we'd benefit from? I think the proposal should include a strong motivation "why"
huoyaoyuan commentedon Feb 12, 2025
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 commentedon Feb 12, 2025
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:
Ubuntu has the following Clang versions (5+):
See:
TL;DR: Therefore, upgrading the C++ compiler feature level to C++ 17 should not be an issue for the Ubuntu platform.
omajid commentedon Feb 18, 2025
RHEL / CentOS Stream
On RHEL (and CentOS Stream) we also use clang to build .NET. Here are the default versions of clang in each:
These are new enough that they should support everything .NET needs from C++ 17
Fedora
These are new enough that they should support everything .NET needs from C++ 17
AaronRobinsonMSFT commentedon Feb 18, 2025
I personally don't see any reason not to move forward in this case.
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
fallthroughattribute or some narrow uses ofconstexpr. Features that we'd likely prefer to avoid are things likestd::string_view,__has_include, nested namespaces or the newfilesystemAPIs.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 commentedon Mar 4, 2025
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.max-charlamb commentedon Aug 13, 2025
#118050 has faced several issues relating to getting the address of a type wrapped by the
VOLATILE(T)macro as aconstexpr. This is challenging asVOLATILE(T)sometimes is thevolatilekeyword and others aVolatile<T>wrapper class. The wrapper class overrides the built-in address-of operator&. This can be solved two different ways with features available in c++17:std::addressofallows getting the address of an object which overrides the&operator as aconstexpr.constexprmember functions. This would allow theVolatile<T>class to override the&operator and provide its address at compile time.Additionally, I see we would benefit from
inline constexprvariables #39532 (comment)Update build to use C++17 compiler standard level