Proposed status of C++20 features for initial support

[Peter Kasting]

C++20 is now on by default for all platforms, and one of the last stages to announce support is to update c++-features.md to cover it. I plan to do this, along with updating PRESUBMIT.py to enforce banned features (where easy).

Historically, we've initially marked everything "TBD" (i.e. banned), which leads to a flurry of proposals to allow clearly-safe things right away, and a lot of flux. So I propose doing more thoughtful marking to start with. Instead of a huge email thread, I've put up a skeleton CL where I briefly name all new features (and the cppreference.com link), along with my rationale for why I've put them in particular lists.

If you would like to have input, please leave review comments on that CL. We can then debate as needed in comments there.

If you have looked at the CL and have no further comments/objections, you can leave a +1 there; I will not actually land until there seems to be consensus (and I have updated these to full-fledged entries like elsewhere in the doc).

P{K

[Bruce Dawson]

While doing some Angle testing with the new toolchain (VS 2022 and the Windows 11 SDK) ynovikov@ and I noticed that abseil (any_invocable_test.cc to be specific) used shared_ptr<T>::unique, which is deprecated in C++17 and goes away in C++20. That is, abseil is actually not compatible with C++20.

The calls to unique() - and some other abseil code - fail in C++20 mode with VC++, which is how this was noticed.

It looks like abseil targets C++14 and C++17 so this isn't really an abseil bug, but something that we should be aware of. Maybe it's worth pushing to get the .unique() calls replaced with use_count() == 1 for greater C++20 compatibility?

[dan...@chromium.org]

On Wed, Feb 15, 2023 at 3:43 PM 'Bruce Dawson' via cxx <c...@chromium.org> wrote:

While doing some Angle testing with the new toolchain (VS 2022 and the Windows 11 SDK) ynovikov@ and I noticed that abseil (any_invocable_test.cc to be specific) used shared_ptr<T>::unique, which is deprecated in C++17 and goes away in C++20. That is, abseil is actually not compatible with C++20.

The calls to unique() - and some other abseil code - fail in C++20 mode with VC++, which is how this was noticed.

It looks like abseil targets C++14 and C++17 so this isn't really an abseil bug, but something that we should be aware of. Maybe it's worth pushing to get the .unique() calls replaced with use_count() == 1 for greater C++20 compatibility?

Interesting. https://github.com/llvm/llvm-project/blob/e6fbfb1ff1d352b2f8f0b6d39f4665fd91f0d21d/libcxx/include/__memory/shared_ptr.h#L866-L870 libc++ did not remove it yet for C++20 mode.

 

On Thursday, February 2, 2023 at 2:11:13 PM UTC-10 Peter Kasting wrote:

C++20 is now on by default for all platforms, and one of the last stages to announce support is to update c++-features.md to cover it. I plan to do this, along with updating PRESUBMIT.py to enforce banned features (where easy).

Historically, we've initially marked everything "TBD" (i.e. banned), which leads to a flurry of proposals to allow clearly-safe things right away, and a lot of flux. So I propose doing more thoughtful marking to start with. Instead of a huge email thread, I've put up a skeleton CL where I briefly name all new features (and the cppreference.com link), along with my rationale for why I've put them in particular lists.

If you would like to have input, please leave review comments on that CL. We can then debate as needed in comments there.

If you have looked at the CL and have no further comments/objections, you can leave a +1 there; I will not actually land until there seems to be consensus (and I have updated these to full-fledged entries like elsewhere in the doc).

P{K

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/24222880-76dd-4ef0-a83e-66b388a45d6cn%40chromium.org.

[dan...@chromium.org]

On Wed, Feb 15, 2023 at 3:48 PM <dan...@chromium.org> wrote:

On Wed, Feb 15, 2023 at 3:43 PM 'Bruce Dawson' via cxx <c...@chromium.org> wrote:

While doing some Angle testing with the new toolchain (VS 2022 and the Windows 11 SDK) ynovikov@ and I noticed that abseil (any_invocable_test.cc to be specific) used shared_ptr<T>::unique, which is deprecated in C++17 and goes away in C++20. That is, abseil is actually not compatible with C++20.

The calls to unique() - and some other abseil code - fail in C++20 mode with VC++, which is how this was noticed.

It looks like abseil targets C++14 and C++17 so this isn't really an abseil bug, but something that we should be aware of. Maybe it's worth pushing to get the .unique() calls replaced with use_count() == 1 for greater C++20 compatibility?

Interesting. https://github.com/llvm/llvm-project/blob/e6fbfb1ff1d352b2f8f0b6d39f4665fd91f0d21d/libcxx/include/__memory/shared_ptr.h#L866-L870 libc++ did not remove it yet for C++20 mode.

Filed https://github.com/llvm/llvm-project/issues/60785

[Peter Kasting]

I can try and patch abseil internally for this.

You are right that abseil does not officially support c++20. We have been relying on our bots to expose problems. This is a case where technically they're in violation, but we didn't notice; for all I know there are other such cases :).

PK

[Bruce Dawson]

The other error that VC++ reported in abseil (after patching in a fix for the unique() issue) can be found here. The critical parts of the error message are:

../../third_party/abseil-cpp\absl/functional/internal/any_invocable.h(860): error C2664: 'ReturnType absl::internal_any_invocable::Impl<Sig>::ExtractInvoker::<lambda_1>::()::<lambda_1>::operator ()(absl::internal_any_invocable::TypeErasedState *,const `anonymous-namespace'::Int &&) noexcept(false) const': cannot convert argument 2 from 'const `anonymous-namespace'::Int' to 'const `anonymous-namespace'::Int &&'
with
[
ReturnType=int,
Sig=int (const `anonymous-namespace'::Int &&) const &
]
../../third_party/abseil-cpp\absl/functional/internal/any_invocable.h(860): note: You cannot bind an lvalue to an rvalue reference

I can't tell if that is a VC++ bug or an abseil bug, but it goes away when we compile as C++17, which is what Angle is doing for now when building with VC++.

--

Bruce Dawson, he/him

[Peter Kasting]

On Wed, Feb 15, 2023 at 1:43 PM Peter Kasting <pkas...@google.com> wrote:

I can try and patch abseil internally for this.

https://critique.corp.google.com/cl/509966011

I don't repro the other error with the existing MSVC toolchain in Chromium. Going to try to patch in the new toolchain and see what happens.

PK

[Bruce Dawson]

The new toolchain is at crrev.com/c/4072083. Don't forget to run "gclient runhooks" (or gclient sync) after patching it in (and when switching away). It will probably become the default toolchain tomorrow.

--

Bruce Dawson, he/him

[Peter Kasting]

On Wed, Feb 15, 2023 at 1:46 PM Bruce Dawson <bruce...@google.com> wrote:

The other error that VC++ reported in abseil (after patching in a fix for the unique() issue) can be found here.

This looks like an MSVC bug to me, but I haven't reduced it to a testcase that can be filed upstream. I did find a workaround (which is what is convincing me that this is likely an MSVC bug): out-of-line the innermost lambda into a static member function. I filed https://b.corp.google.com/issues/269536242 on this, which links to a diff for my workaround if anyone needs it. I don't really have time to try and reduce this/file upstream, so help there would be appreciated.

PK 

[Bruce Dawson]

Somebody else created a minimal repro and filed a bug:

https://github.com/abseil/abseil-cpp/issues/1383

There is some discussion of it here:

https://twitter.com/TartanLlama/status/1626231310758060032

--

Bruce Dawson, he/him