Rolling out C++23

82 views
Skip to first unread message

Victor Vianna

unread,
Nov 18, 2025, 11:48:19 PMNov 18
to c...@chromium.org, Nico Weber, rby...@chromium.org
Hi cxx,

Apart from a few last pending CLs, building with use_cxx23=true now works on chromium/src and all other projects I could find that pull //build (e.g. dawn, angle, ...). See this spreadsheet, which links to smoke test CLs in each project.

Is anyone aware of any blockers beyond the ones below?
  1. Investigate the binary size regressions [1][2]
  2. Check if the change works with libchrome
Otherwise, once I address the items above, I would like to start sending heads-ups to stakeholders (playbook) and eventually proceed with the rollout.

- Victor

Daniel Cheng

unread,
Nov 19, 2025, 1:13:56 AMNov 19
to Victor Vianna, c...@chromium.org, Nico Weber, rby...@chromium.org
The binary size growth doesn't look that bad and I'd say it's fine to ignore. The bigger issue is the compile size bots: a nearly 4% gain is pretty substantial. But I'm also not sure if there's much we can do; most likely the standard library headers just include more stuff because C++23 has more functionality. It might be nice to see what headers are growing the most, and looking for any low-hanging fruit where a more-specific include might shrink the compile inputs a bit. I'd probably start with https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8697821049190203521/+/u/Write_size_results/compile_size_deltas.txt and try diffing the preprocessed output (with -E) to try to see where the growth is coming from. It might be useful to do a file with a relatively small increase (e.g. printing/nup_parameters.cc) and a file with a huge increase (e.g. base/byte_count.cc or printing/page_range.cc–the latter looks quite interesting given the minimal size of the file and the minimal direct includes).

Besides libchrome, it would be good to reach out to cronet now as well, to make sure their toolchain supports C++23.

Also, for anyone following along, the tracking bug for migrating to C++23 is https://crbug.com/388070065.

Finally, I'd suggest starting the conversation around allowed and disallowed C++23 features, since there might be a bit of research involved.

Daniel

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CANFyMwzg4S0djS%2Bh0-cE3LGbn%3DCtmxGeATPbBUo1zcP7oANpSA%40mail.gmail.com.

Nico Weber

unread,
Nov 19, 2025, 12:12:52 PM (14 days ago) Nov 19
to Daniel Cheng, Victor Vianna, c...@chromium.org, rby...@chromium.org, Erik Staab, Stefano Duo, Takuto Ikuta
Cool!

Re compile size increase: We enabled clang's header modules on most bots, which should mitigate the effect of the standard library size increase some. I think the compile size bot might not take modules into account (but not sure; estaab might know).

We got agreement from the libchrome folks that libchrome isn't our problem, and we shouldn't worry about them when doing toolchain upgrades and the like.

cronet's toolchain isn't exactly the same revision as chromium's, but it should be around the same age these days. stefanoduo, what's a good way to check if switching to c++23 works for you?

Nico Weber

unread,
Nov 19, 2025, 12:13:55 PM (14 days ago) Nov 19
to Daniel Cheng, Victor Vianna, c...@chromium.org, rby...@chromium.org, Erik Staab, Stefano Duo, Takuto Ikuta
Oh, finally re binary size: For bigger changes, PGO profiles being out of date sometimes causes a temporary binary bump that recovers once profiles are updated. (I don't know if we use PGO on the Fuchsia bots, though.) Maybe just landing and seeing if it recovers might work.

Stefano Duo

unread,
Nov 19, 2025, 12:28:48 PM (14 days ago) Nov 19
to Nico Weber, Daniel Cheng, Victor Vianna, c...@chromium.org, rby...@chromium.org, Erik Staab, Takuto Ikuta
I believe it should be possible to enable c++23 for Cronet without issues. The best way to confirm this would be to run Cronet's trybots on the CL that moves Chromium to c++23. This can be done by adding to your CL:

Cq-Include-Trybots: luci.chrome.try:cronet-arm64-gn2bp-debug

Hidehiko Abe

unread,
Nov 19, 2025, 1:30:01 PM (14 days ago) Nov 19
to Stefano Duo, Nico Weber, Daniel Cheng, Victor Vianna, c...@chromium.org, rby...@chromium.org, Erik Staab, Takuto Ikuta, Di Wu, Satoru Takabayashi, Lei Zhang


2025年11月20日(木) 2:28 'Stefano Duo' via cxx <c...@chromium.org>:
I believe it should be possible to enable c++23 for Cronet without issues. The best way to confirm this would be to run Cronet's trybots on the CL that moves Chromium to c++23. This can be done by adding to your CL:

Cq-Include-Trybots: luci.chrome.try:cronet-arm64-gn2bp-debug

On Wed, Nov 19, 2025 at 5:13 PM Nico Weber <tha...@chromium.org> wrote:
Oh, finally re binary size: For bigger changes, PGO profiles being out of date sometimes causes a temporary binary bump that recovers once profiles are updated. (I don't know if we use PGO on the Fuchsia bots, though.) Maybe just landing and seeing if it recovers might work.

On Wed, Nov 19, 2025 at 12:12 PM Nico Weber <tha...@chromium.org> wrote:
Cool!

Re compile size increase: We enabled clang's header modules on most bots, which should mitigate the effect of the standard library size increase some. I think the compile size bot might not take modules into account (but not sure; estaab might know).

We got agreement from the libchrome folks that libchrome isn't our problem, and we shouldn't worry about them when doing toolchain upgrades and the like.

While I wouldn't say libchrome is the hard blocker here, but I still think it's nice if we can coordinate between chromium and chromeos for better maintenance.
Last time on updating C++ from 17 to 20, Peter Kasting and I did that thing actually, and I believe it went very well.
First, any (even rough) timelines of the plan? IIRC, last time, flipping the flag and the timing people start using new libraries/features had some gap. Will this be the same this time, too?

Thanks,
- hidehiko

 

cronet's toolchain isn't exactly the same revision as chromium's, but it should be around the same age these days. stefanoduo, what's a good way to check if switching to c++23 works for you?

On Wed, Nov 19, 2025 at 1:13 AM Daniel Cheng <dch...@chromium.org> wrote:
The binary size growth doesn't look that bad and I'd say it's fine to ignore. The bigger issue is the compile size bots: a nearly 4% gain is pretty substantial. But I'm also not sure if there's much we can do; most likely the standard library headers just include more stuff because C++23 has more functionality. It might be nice to see what headers are growing the most, and looking for any low-hanging fruit where a more-specific include might shrink the compile inputs a bit. I'd probably start with https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8697821049190203521/+/u/Write_size_results/compile_size_deltas.txt and try diffing the preprocessed output (with -E) to try to see where the growth is coming from. It might be useful to do a file with a relatively small increase (e.g. printing/nup_parameters.cc) and a file with a huge increase (e.g. base/byte_count.cc or printing/page_range.cc–the latter looks quite interesting given the minimal size of the file and the minimal direct includes).

Besides libchrome, it would be good to reach out to cronet now as well, to make sure their toolchain supports C++23.

Also, for anyone following along, the tracking bug for migrating to C++23 is https://crbug.com/388070065.

Finally, I'd suggest starting the conversation around allowed and disallowed C++23 features, since there might be a bit of research involved.

Daniel

On Tue, 18 Nov 2025 at 20:48, 'Victor Vianna' via cxx <c...@chromium.org> wrote:
Hi cxx,

Apart from a few last pending CLs, building with use_cxx23=true now works on chromium/src and all other projects I could find that pull //build (e.g. dawn, angle, ...). See this spreadsheet, which links to smoke test CLs in each project.

Is anyone aware of any blockers beyond the ones below?
  1. Investigate the binary size regressions [1][2]
  2. Check if the change works with libchrome
Otherwise, once I address the items above, I would like to start sending heads-ups to stakeholders (playbook) and eventually proceed with the rollout.

- Victor

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CANFyMwzg4S0djS%2Bh0-cE3LGbn%3DCtmxGeATPbBUo1zcP7oANpSA%40mail.gmail.com.

--
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.

Erik Staab

unread,
Nov 19, 2025, 8:18:06 PM (13 days ago) Nov 19
to Hidehiko Abe, Stefano Duo, Nico Weber, Daniel Cheng, Victor Vianna, c...@chromium.org, rby...@chromium.org, Takuto Ikuta, Di Wu, Satoru Takabayashi, Lei Zhang
Re compile size: the compile size builder isn't using modules and there are folks very actively driving down the compiler input size still. I think we're at a point where we need to decide if we're going all in on modules or if we need to continue to keep non-modules compile size growth in check. AFAIK clangd doesn't work with modules so that's at least one place where we'll see a performance hit and I'm not sure if there are others.

That said, because of the great work people have done to drive down size since we spun up the compile size builder, a 4% regression will still be well under the 12 month peak on chrome-includes (history).

Thanks,
Erik
Reply all
Reply to author
Forward
0 new messages