Changing default C++ mode to C++20

Clang Frontend
1

We (Sony) want to change the default C++ mode to C++20 soon for PS5.

I assume that the Clang community will also want to take that step sometime.
So, we would like to know what the plans for Clang are, and any other high-level thoughts about the approach.

There are about 60 lit tests that fail if we change the default to C++20, understandably. The fix for them will be on a case-by-case basis. Some files will have to be split, others can be handled by selective FileCheck patterns.

Any guidance will be appreciated.

sunil.srivastava@sony.com

1 Like
2

Personally (not speaking as a maintainer), I don’t think we’re ready yet. We do not yet conform to C++20 (https://clang.llvm.org/cxx_status.html), so it seems premature for us to switch to that as the default language mode upstream until we’re actually feature complete and stable.

But you’re right that we’re going to change the default at some point and we should prepare for it. So it might make sense for us to put up a post-commit build bot where C++20 is the default language mode and start fixing up those tests. The bot will help ensure we don’t make the migration harder on ourselves in the future. IIRC, we’ve already got a bot (I think from Sony?) that defaults to C99 instead of C17 and that’s been helpful in catching those kinds of issues.

2 Likes
3

Thanks for the feedback @AaronBallman. We do plan to bring up a bot that builds/tests using C++20 as the default. The exact details are still being determined internally, but we agree that it would be a good way to get things ready as well as make sure things stay ready until we make the change to the defaults for everyone.

4

Agreed. Note that there is a C++20-tracking project with a lot of semi-critical bugs C++ 20 in Clang · GitHub
Even if it’s technically a C++23 feature, having import std; work reliably seems important before switching the default.

Full list of issues GitHub · Where software is built

That being said, having a bot defaulting to c++20 would be lovely

2 Likes
5

I don’t think support for import std – nor modules at all – need to be a prerequisite. IMO, if Clang had solid support for everything in C++20 except Modules, it would still be reasonable to change the default language version.

However, given there are a number of issues with coroutines and concepts too, I kinda agree that it’s not yet time to change the default version quite yet. Yet…inside Google we’ve been successfully using C++20 mode for quite a while now, which one could take to mean those issues needn’t really be considered blockers. Shrug, I dunno…

6

IF I thought we could get away with it, I’d say we should remove the ‘default’ entirely, compiling without giving a version flag would be an error.

I PERSONALLY get screwed by there being a default/not knowing what it is pretty frequently, so it would save me from myself :slight_smile:

7

and … we still have at least one spaceship DR that turned into an EWG issue pending: Clang doesn't recognize friend operator!= to resolve ambiguity in operator== · Issue #70210 · llvm/llvm-project · GitHub

8

This seems to be a breaking change. I think we can’t do that or it doesn’t worth.

9

Breaking change? Perhaps. I’m not the first to have floated this idea, the point is that changing the default standards mode IS a breaking change for anyone who doesn’t have -std=xxx in their build scripts, but we consider those people WRONG, and breakable.

Removing the default would follow the same logic for that.

10

All C++ compilers have a default language mode, so it would be kind of odd for Clang to be the only one to drop support for it. User expectation is that new language modes don’t break their working code, only introduce new features, so having a default language mode should (in theory) be reasonable. WG21 constantly breaking working code both with new language modes and in older language modes through defect reports shows a bit of a disconnect between the committee and users.