Bump V8 to 14.5

[ketanhwr]

Patch 29 has been upstreamed: https://chromium-review.googlesource.com/c/v8/v8/+/7124103

[codspeed-hq]

Merging this PR will degrade performance by 38.91%

⚡ 12 improved benchmarks
❌ 5 regressed benchmarks
✅ 53 untouched benchmarks
⏩ 129 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	JsString_Utf8Length_Utf16_NonFlat_8192	73.7 µs	25 µs	×2.9
⚡	JsString_Utf8Length_Utf16_NonFlat_1024	16.1 µs	10.8 µs	+48.76%
⚡	Encode_TwoByte_1024[TextEncoder][0/2/1024]	19.5 ms	16.3 ms	+19.11%
❌	Encode_ASCII_32[TextEncoder][0/0/32]	2.9 ms	3.4 ms	-14.72%
⚡	Encode_TwoByte_256[TextEncoder][0/2/256]	7 ms	6.4 ms	+9.54%
⚡	Encode_TwoByte_8192[TextEncoder][0/2/8192]	146.1 ms	119.4 ms	+22.4%
❌	EncodeInto_ASCII_8192[TextEncoder][1/0/8192]	3.3 ms	3.6 ms	-10.32%
⚡	JsString_Utf8Length_Latin1_Flat_1024	4.6 µs	3.1 µs	+45.18%
⚡	JsString_Utf8Length_Latin1_NonFlat_8192	41.9 µs	24.9 µs	+67.92%
❌	JsString_Utf8Length_Latin1_Flat_256	1.7 µs	2 µs	-12.72%
❌	JsString_Utf8Length_Latin1_Flat_32	891.1 ns	1,458.6 ns	-38.91%
⚡	JsString_Utf8Length_Latin1_NonFlat_1024	12.1 µs	10.8 µs	+12.47%
⚡	JsString_Utf8Length_Latin1_Flat_8192	31 µs	14 µs	×2.2
❌	JsString_Utf8Length_Utf16_Invalid_Flat_256	2.7 µs	3.2 µs	-15.61%
⚡	JsString_Utf8Length_Utf16_Flat_256	2.7 µs	2 µs	+37.12%
⚡	JsString_Utf8Length_Utf16_Flat_8192	62.9 µs	14.1 µs	×4.5
⚡	JsString_Utf8Length_Utf16_Flat_1024	8.6 µs	3.2 µs	×2.7

---

_{Comparing ketan/v8-14.5 (51d0950) with main (c9203d3)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ketanhwr]

Hmm arm build is failing due to a legitimate reason.. checking This is fixed now.. onto the windows build failure.. this is fixed now as well

[ketanhwr]

Okay so:

• arm failure was due to v8's bazel build being out-of-sync with their GN file (patch 31 addresses that)
• I still don't completely understand the windows build failure (example logs here), but this change (https://chromium-review.googlesource.com/c/v8/v8/+/7200625) introduced a path which MSVC presumably doesn't really handle well (or rather differently than linux libc++).. In patch 32, I changed the lambda to accept auto&& instead of std::function& and that seems to work.

@fhanau let me know if you're happy with these 2 additional patches

[fhanau]

Okay so:

• arm failure was due to v8's bazel build being out-of-sync with their GN file (patch 31 addresses that)
• I still don't completely understand the windows build failure (example logs here), but this change (https://chromium-review.googlesource.com/c/v8/v8/+/7200625) introduced a path which MSVC presumably doesn't really handle well (or rather differently than linux libc++).. In patch 32, I changed the lambda to accept auto&& instead of std::function& and that seems to work.

@fhanau let me know if you're happy with these 2 additional patches

• It appears that the first failure is due to a problem under debug builds, not arm64 builds (we just happen to have the debug CI job use arm64 since it's slightly faster).
• I assume this is an issue with the source files themselves not supporting builds with debug mode on (could be one of several debug-related defines) but V8_VERIFY_WRITE_BARRIERS being off (which would be a problem with V8 itself). I think in this case it's less likely that it's an issue with the bazel configuration, which is poorly maintained and does not enable V8_VERIFY_WRITE_BARRIERS in debug builds by default whereas the GN build does, but that mode should still be supported. If this can be fixed on the source level by changing some defines, V8 would probably accept a patch (non-blocking).
• Note that we use clang-cl instead of MSVC to build on Windows – MSVC is no longer supported by V8. Not sure what's causing the issue here – could be that clang-cl is not officially supported (regular clang is supported, but comes with a bunch of other headaches on Windows so it would be difficult to use that), could be a difference in compiler versions or an issue with the bazel configuration again. I think the proposed fix is fine – if const auto& would also work I think that's preferable but I'm ok with auto&& fn too.

LGTM overall.

[ketanhwr]

Oh yes, they're specific to debug builds, you're right. I'll take a look at an upstream patch when I get some time..
For the windows issue - const auto&& doesn't work unfortunately, so I'm going to merge this PR as-is.
Thanks for reviewing!