[v18.x] deps: V8: cherry-pick d15d49b09dc7
Original commit message:
Make bitfields only as wide as necessary for enums
clang now complains when a BitField for an enum is too wide.
We could suppress this, but it seems kind of useful from an
uninformed distance, so I made a few bitfields smaller instead.
(For AddressingMode, since its size is target-dependent, I added
an explicit underlying type to the enum instead, which suppresses
the diag on a per-enum basis.)
This is without any understanding of the code I'm touching.
Especially the change in v8-internal.h feels a bit risky to me.
Bug: chromium:1348574
Change-Id: I73395de593045036b72dadf4e3147b5f7e13c958
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794708
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82109}
Refs: https://github.com/v8/v8/commit/d15d49b09dc7aef9edcc4cf6a0cb2b77a0db203f Fixes: #52230 (closed)
(Note that this change is already in the baseline v8 of v20.x and newer, hence why this is a v18-only cherry-pick)
I carefully combed through this patch. The NodeState
changes (include/v8-internal.h
and src/handles/global-handles.cc
) are not included, as the enum on v18.x is slightly larger (v18.x vs at time of v8 patch) so the current 3 bits is correct. And just to check: make jstest
was able to catch this correctly.
I can confirm this patch fixes the build on Xcode 15.3.
We also have advance notice that this will be a hard error in LLVM Clang 19 (later this year) so -Wno-enum-constexpr-conversion
would not have been a long-term fix:
The warning -Wenum-constexpr-conversion is now also enabled by default on system headers and macros. It will be turned into a hard (non-downgradable) error in the next Clang release.
https://releases.llvm.org/18.1.0/tools/clang/docs/ReleaseNotes.html