Proposal: Use C++20

[graham33]

Would there be an objection to using C++20 for the Nix codebase? We are working on a future patch (related to S3) that might benefit from C++ 20, so thought it was worth raising a PR to upgrade to see if it's feasible. I'm not sure what the constraints are for compatibility in various environments.

[thufschmitt]

We're already using some C++20 features in practice (designated initializers is the first that comes to my mind but I think there's a couple other things). So if something requires C++20, I don't see any objection towards fully making the switch.

Deferring to @edolstra or the rest of the maintainers though for a final call

[edolstra]

The compilers we're currently using don't support all of C++20. So we can only use some features like designated initializers.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/tweag-nix-dev-update-38/22805/1

[thufschmitt]

@edolstra which compilers are you refeering to? The darwin builds used to have a very old clang, but it is now using clang 11 Afaik (which technically doesn't support the whole of c++20, but close-enough). Is there anything else blocking us there?

[edolstra]

I was mostly thinking about gcc, but it looks like the support for C++20 in gcc/libstdc++ 11 is pretty good now:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html
https://gcc.gnu.org/projects/cxx-status.html#cxx20

[graham33]

Yes I think gcc 11's support for C++20 is pretty good. See also https://en.cppreference.com/w/cpp/compiler_support

[edolstra]

Thanks, I just needed this for std::span on the lazy-trees branch!

[roberth]

Looks like CI doesn't run on a an up to date merge commit, as this merge has broken master.

Bors could help us prevent this.

[edolstra]

Weird, I did test a version of this rebased on master.

[roberth]

Maybe it only happens on clang.
The build failure came from the darwin job (but the linux one was cancelled because of that fwiw).

[edolstra]

It also fails on aarch64-linux, though with a different error:

g++: error: unrecognized command line option '-std=c++20'; did you mean '-std=c++2a'?

Looks like we're using an older version of gcc (9.3.0) on aarch64-linux... 😖 According to NixOS/nixpkgs/00a0eeb2cb9f63b42dbc15d4a15b5d2a403852f5 this is because of "unresolved issues".

[roberth]

Not compatible with boehmgc, it seems. NixOS/nixpkgs#174282 (comment) I misread.

That's rather non-optional. Maybe we're not quite ready for C++20 then. Might c++2a be a viable solution, despite being insufficiently descriptive? Otherwise we'll have to revert this. That may actually be the best option until the boehmgc compatibility is resolved.

[roberth]

There's a tracking issue

• stdenv: let aarch64 use gcc ≥10 nixpkgs#108305

[edolstra]

Or we use gcc11Stdenv on aarch64-linux.

It would be rather sad to revert this because aarch64-linux is stuck indefinitely on an old version of gcc. That cannot be a maintainable situation for nixpkgs either. It kind of defeats the purpose of a standard environment if stdenv on some architectures has a different version of gcc...

[roberth]

• stdenv: Nix-driven bootstrap of gcc nixpkgs#209870 lists gcc on arm as its first immediate benefit; also of interest to @Ericson2314

[roberth]

Or we use gcc11Stdenv on aarch64-linux.

I wonder what bugs we'd be getting ourselves into, and isn't this risky to combine with non-gcc-11 packages?

purpose of a standard environment

I don't think that's the reason for the name, but I agree.

[roberth]

I'm afraid that this upgrade will send us down a very counterproductive rabbit hole. Is there a reasonable alternative to std::span you could use?

[edolstra]

Of course, but being stuck on an outdated version of gcc is not a viable long-term situation.

[tpwrules]

This might be a more relevant tracking/goal issue: NixOS/nixpkgs#208412

TL;DR: We have a solution to upgrade GCC on aarch64-linux for now (upgrade the bootstrap tarball) and intend to have it in by NixOS 23.05. But it doesn't fix the underlying problems and is likely to cause the version to get stuck again. We are putting in significant effort on more comprehensive solutions so we can fix the issue for good but the issues are quite non-trivial.

My vote would be to revert this until a solution is merged into nixpkgs. I would worry about mixing the GCC version of such a fundamental package, and there is the possibility of rare and hard to detect bugs being induced with GCC 11 (which is why it hasn't been upgraded yet).

[vcunat]

The mixing sounds problematic just for packages that link against nix libs. They will probably be forced to use the same compiler version (because C++ ABI).