Core: Bump C++ Standard to C++20

[Repiteo]

• Supersedes Core: Support c++20 compilation #89660

In contrast to the above PR, which attempted to simultaneously support C++17 alongside later standards, this PR aims to make our baseline C++20 outright. The immediate benefit is removing the need for several workarounds via macros & #if __cplusplus wrappers, making for a much cleaner codebase overall. The much, much bigger benefit is the freedom to actually integrate C++20 features, allowing this PR to satisfy our contribution Best Practices & not exist as a solution looking for a problem.

EDIT: After a core meeting, it was instead decided that integrations of features would be best handled in entirely separate PRs, so that we can pick-and-choose which features are best to integrate. While that dampens the effect of this PR in isolation, it's now doing so with the knowledge that it will not exist in isolation and would soon be followed with proper integrations of the new features that the repo would directly benefit from. Future edits of this OP will point to specific discussions/implementations of said features up until this is merged.

[AThousandShips]

Has the concerns with support for c++20 on niche compilers like those for various console ports been resolved? That has been the main thing holding this back other than just the workload, we really don't want various porting providers running afoul of this

[Repiteo]

I'm not certain if that's been resolved, and I certainly wouldn't want this merged before that was the case either. Things like Android will already need to be updated to accomodate C++20, so I know this wouldn't happen straight away no matter what. Regardless, this PR operating under the assumption that it will be supported; that way it can get a kick-start on actually integrating features & we won't have to do any #ifdef song-and-dance

[AThousandShips]

Absolutely, generally absolutely in favor of adding various new QOL features from C++20, brought it up in the platforms channel and we'll see what information we can dig up

[hpvb]

I want to throw my support behind the concept of moving to c++20, in particular it will give us access to:

https://en.cppreference.com/w/cpp/utility/source_location

Which will allow us to instrument our builds better, allowing us to log where our error macros happen. So instead of getting a message that p_index is out of range in cowdata, we could potentially log where the actual call that went out of index happened instead.

It'll take a bit of doing, but I think that that alone is worth the upgrade.

[Repiteo]

Oh wow, that looks extremely useful! The header looks pretty lightweight, similar to <initializer_list>, _{(aka: something that should've just been a language feature)} so I think making an exception and adding that header this PR would be entirely reasonable. It'd all depend on how easily it could be integrated of course, but I can see it as part of a broader commit which revamps the error macros with other new C++20 functionality (eg: <compare> library functions for mixed-sign indices, concepts for passing classes with is_null() functions to ERR_FAIL_NULL_* instead of ERR_FAIL_COND_*(val.is_null()), etc)

[hpvb]

Oh wow, that looks extremely useful! The header looks pretty lightweight, similar to <initializer_list>, (aka: something that should've just been a language feature) so I think making an exception and adding that header this PR would be entirely reasonable. It'd all depend on how easily it could be integrated of course, but I can see it as part of a broader commit which revamps the error macros with other new C++20 functionality (eg: <compare> library functions for mixed-sign indices, concepts for passing classes with is_null() functions to ERR_FAIL_NULL_* instead of ERR_FAIL_COND_*(val.is_null()), etc)

Maybe we should aim low for this initially then. Do your first 2 commits as separate PRs, at that point we technically have a C++20 codebase, we can then start using std::source_location and we can look at the other new features of C++20 on case-by-case basis?

I think there's things in this still that are more controversial than just the switch to a newer standard.

[Repiteo]

After some local testing, it'd definitely be more involved than this PR should reasonably change. While using it as a drop-in replacement for FUNCTION_STR/__FILE__/__LINE__ technically works, it doesn't appear to solve the issue of error macros reporting their own scope. It'd certainly make for prettier output, and we'd be able to pass column info too, but otherwise outer-scope awareness appears to require a major rework.

[Repiteo]

Maybe we should aim low for this initially then.

That's what I'm already doing tbh. Everything else I've tried to dig into has felt like it goes beyond the scope of drop-in QOL bumps, so the changes remained conservative (albeit wide-reaching). I could maybe see myself reverting the three-way comparison commit if people are THAT skeptical (even if its inclusion is an inevitability), but none of the others strike me as intrusive or contentious.

[hpvb]

After some local testing, it'd definitely be more involved than this PR should reasonably change. While using it as a drop-in replacement for FUNCTION_STR/__FILE__/__LINE__ technically works, it doesn't appear to solve the issue of error macros reporting their own scope. It'd certainly make for prettier output, and we'd be able to pass column info too, but otherwise outer-scope awareness appears to require a major rework.

Oh yeah, it is. I did say "It'll take some doing", but because it is a type it can be put in template parameters, so we can schlep it around to the macro site. I wasn't suggesting we do it in this PR, I just think having C++20 is a prerequisite to starting doing it!

[radiantgurl]

As im currently working on refactoring Variant, i feel like concepts from C++20 would be extremely helpful allowing us to more easily register them and remove clutter. I'm imagining a system that would only require you to modify the class itself and everything else would handle itself.

[Ivorforce]

Since we're apparently using this thread to add to the c++20 wish list:

• no_unique_address could help by allowing us to easily add Vector-like .write semantics to more types.
• Differentiate C literals from utf8 literals (char8_t)
• Fast paths for constants (consteval)
• std::bit_cast for constexpr purposes

Probably more that I forgot :)

[hpvb]

From the core meeting: We're requesting reviews from the people assigned. If we approve we will merge this for 4.5.

Main questions are around the effects on the C# bindings and GDExtension compatibility.

[Ivorforce]

Looks great! I can't find anything to be sceptical about - you've really boiled this PR down to its essentials (except the equality changes, I guess. But that's mostly code removal.)

One thing caught my eye - I'm seeing you adding a few equality comparisons that weren't there previously. Is this because automatic conversions are no longer applied when you're removing the operator!= versions?

[Ivorforce]

Could you quickly explain what was happening earlier, and why it's no longer possible in c++20?

[Repiteo]

The short version is implicit conversion operators have finally bitten us in the ass

The long version is that C++20's way of adding new overloads for comparison operators means that there's now a lot more room for ambiguous comparisons. In particular, the synthesized comparisons mean that multiple ways of handling an implicit conversion can occur. This is surprisingly difficult to articulate, but a somewhat straightforward example reveals itself when trying to compile without these operators:

platform\windows\display_server_windows.cpp(2970): error C2666: 'Variant::operator ==': overloaded functions have similar conversions
D:\Godot\godot\core/variant/variant.h(816): note: could be 'bool Variant::operator ==(const Variant &) const'
D:\Godot\godot\core/object/ref_counted.h(104): note: or 'bool Ref<Resource>::operator ==(const Ref<Resource> &) const' [synthesized expression 'y == x']
platform\windows\display_server_windows.cpp(2970): note: while trying to match the argument list '(const T, const Ref<Resource>)'
        with
        [
            T=Variant
        ]
platform\windows\display_server_windows.cpp(2970): error C2666: 'Variant::operator ==': overloaded functions have similar conversions
D:\Godot\godot\core/variant/variant.h(816): note: could be 'bool Variant::operator ==(const Variant &) const'
D:\Godot\godot\core/math/vector2.h(160): note: or 'bool Vector2::operator ==(const Vector2i &) const' [synthesized expression 'y == x']
D:\Godot\godot\core/math/vector2.h(247): note: or 'bool Vector2::operator ==(const Vector2 &) const' [synthesized expression 'y == x']
platform\windows\display_server_windows.cpp(2970): note: while trying to match the argument list '(const T, const Vector2)'
        with
        [
            T=Variant
        ]

The relevant code in question:

void DisplayServerWindows::cursor_set_custom_image(const Ref<Resource> &p_cursor, CursorShape p_shape, const Vector2 &p_hotspot) {
	_THREAD_SAFE_METHOD_

	ERR_FAIL_INDEX(p_shape, CURSOR_MAX);

	if (p_cursor.is_valid()) {
		RBMap<CursorShape, Vector<Variant>>::Element *cursor_c = cursors_cache.find(p_shape);

		if (cursor_c) {
			if (cursor_c->get()[0] == p_cursor && cursor_c->get()[1] == p_hotspot) {
...

In all likelyhood, we've probably been dodging several ambiguous bullets on live and/or are already footgunning ourselves without even realizing it. This entire setup will need a more thorough review, likely accompanied with a re-evaluation of the implicit conversion of Variant, but this is very much a stopgap solution to maintain the same comparison functionality as llive.

[Ivorforce]

This should be tracked with a follow-up issue. I assume not deleting it won't cause problems in the meantime?

[Repiteo]

It will not cause problems, no. This was relying on a quirk of pre-c++20 construction that bypassed a deleted constructor with {} initialization. In practice, this class is only used internally, and making it truly closed off could still be done if desired via friend constructors or a static method, but that felt outside the scope of this PR.

[Repiteo]

One thing caught my eye - I'm seeing you adding a few equality comparisons that weren't there previously. Is this because automatic conversions are no longer applied when you're removing the operator!= versions?

It's swapping out a "secondary" comparison operator for a "primary" one. C++20 makes synthesized operators from the primary ones, so it achieves the same result as before but allows for equality operation as well. A lot of this is admittedly more bloated than it should be, as many of the changes in C++20 were made with utilizing defaulted comparison operators & three-way comparison <=> in mind, but that'll be for a followup PR which explicitly adds those new features

[Repiteo]

Revisited the structure after the core meeting, and managed to significantly decrease the number of changed files/lines. To ensure C++17 compatibility, there's no more removed operators; only additional operators to account for the ambiguous cases in C++20.

• Before: 79 files, 568 lines
• After: 22 files, 317 lines

I don't believe that there's any real way to circumvent the Variant operator bloat, as it otherwise requires a VERY invasive number of changes. As the comment notes, it's an area that can be revisited with a more general pass later.

[dsnopek]

This looks good to me! There's nothing that seems particularly dangerous or problematic for the areas of the engine I usually work in

[Ivorforce]

I appreciate that you got it even more minimal!

[raulsntos]

I tried compiling this branch and I'm getting these warnings:

modules/mono/csharp_script.cpp:1110:59: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'GCHandleIntPtr' and 'GCHandleIntPtr') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
        if (!r_gchandle.is_released() && r_gchandle.get_intptr() == p_gchandle_to_free) { // Do not lock unnecessarily
                                         ~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~
modules/mono/mono_gd/../mono_gc_handle.h:48:22: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
        _FORCE_INLINE_ bool operator==(const GCHandleIntPtr &p_other) { return value == p_other.value; }
                            ^
modules/mono/csharp_script.cpp:1112:60: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'GCHandleIntPtr' and 'GCHandleIntPtr') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
                if (!r_gchandle.is_released() && r_gchandle.get_intptr() == p_gchandle_to_free) {
                                                 ~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~
modules/mono/mono_gd/../mono_gc_handle.h:48:22: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
        _FORCE_INLINE_ bool operator==(const GCHandleIntPtr &p_other) { return value == p_other.value; }
                            ^
modules/mono/csharp_script.cpp:1120:55: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'GCHandleIntPtr' and 'GCHandleIntPtr') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
        if (!gchandle.is_released() && gchandle.get_intptr() == p_gchandle_to_free) { // Do not lock unnecessarily
                                       ~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~
modules/mono/mono_gd/../mono_gc_handle.h:48:22: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
        _FORCE_INLINE_ bool operator==(const GCHandleIntPtr &p_other) { return value == p_other.value; }
                            ^
modules/mono/csharp_script.cpp:1122:56: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'GCHandleIntPtr' and 'GCHandleIntPtr') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
                if (!gchandle.is_released() && gchandle.get_intptr() == p_gchandle_to_free) {
                                               ~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~
modules/mono/mono_gd/../mono_gc_handle.h:48:22: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
        _FORCE_INLINE_ bool operator==(const GCHandleIntPtr &p_other) { return value == p_other.value; }
                            ^

However, it finishes building and everything appears to work as expected.

[Repiteo]

I tried compiling this branch and I'm getting these warnings:

Interesting that didn't cause warnings on our CI. Still, that's probably caused by the equality operators in that class not being const, so hopefully tweaking that over does the trick

[raulsntos]

Not getting any warnings now, and I see no problems with this for the .NET area.

[Calinou]

Tested locally on Windows 11 24H2 with MSVC 2022, it works as expected. I've also tested an Ubuntu 22.04 Docker container and Godot can still be built.

Note that this makes it no longer possible to compile Godot on Ubuntu 20.04 (unless you install a more recent GCC/Clang through third-party repositories), but 20.04 is EOL since April 2025 anyway.

Code looks good to me.

Some notes:

• Is MSVC 2019 tested (on its latest update) to make sure it works? I don't have it installed, but I don't remember if it has full C++20 support.
• Using Apple's Clang, is it still possible to compile on old macOS versions like 10.15 or 11? We still support 10.15 currently, although only with the Compatibility renderer. It's not a big deal if it can't be compiled on 10.15 anymore, as long as binaries compiled on newer macOS versions still work there.

[Benjamin-Dobell]

I've been using this branch (its various incarnations) almost exclusively for around 6 months. Mostly targeting macOS and Android.

Re: macOS, I haven't changed anything from the defaults, the resulting binaries are currently minimum macOS 11.0:

Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 11.0
      sdk 15.5
   ntools 1
     tool 3
  version 1167.5

macOS 11 was released just over 5 years ago and can be installed on devices that are over 10 years old (https://support.apple.com/en-au/103111). Obviously this isn't my call to make, and I don't know what the current minimum version is, but requiring macOS 11 seems reasonable for a runtime constraint.

Not exactly sure about the minimum macOS version required to build. I believe macos-latest (Github Actions) was pointing at macOS 14 (now two years old) when this PR was initially opened. So we've at least got a couple of years of support for building. I'm still running macOS 15 (one year old) myself.

[bruvzg]

macOS, I haven't changed anything from the defaults, the resulting binaries are currently minimum macOS 11.0

Is it ARM64 or x86-64 binary? For ARM64 minimum version Godot targets is 11.0, since it's the first OS release on Apple Silicon, for x86-64 it's 10.13 (but in support is only partial, only Vulkan won't work on it or 10.14).

Not exactly sure about the minimum macOS version required to build.

Godot uses macOS 15 features, so min. version of Xcode required to compile it is 16.0 which runs on macOS 14.5.

[Benjamin-Dobell]

That was an arm64 binary. I've just built for x86_64. I don't really have a good way to test it unfortunately. I've tried to dust off (literally) my old Intel Macbook 15, but apparently it won't boot 😅

However, all indications are the build is at least trying to target 10.13:

ld: warning: object file (/Users/ben/Development/VulkanSDK/1.4.304.1/macOS/lib/MoltenVK.xcframework/macos-arm64_x86_64/libMoltenVK.a[x86_64][2](libMoltenVK.a-x86_64-master.o)) was built for newer 'macOS' version (10.15) 
than being linked (10.13)

Looks like my MoltenVK is built for 10.15. Not sure if there are 10.14 builds out there. EDIT: Just re-read your comment and realized you were saying 10.15 is the expected minimum. So this lines up.

[bruvzg]

Tested various builds, and did not encounter any issues. Code looks good to me. Is there anything that still blocking this?