Original commit message:
PPC/s390: [wasm][liftoff] Always zero-extend 32 bit offsets
Port 2b77ca200c56667c68895e49c96c10ff77834f09
Original Commit Message:
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ife3ae4f93b85fe1b2c76fe4b98fa408b5b51ed71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929661
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74886}
Refs: 3805a698f7
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm][arm64] Always zero-extend 32 bit offsets, for realz
We've already been zero-extending 32-bit offset registers since
https://chromium-review.googlesource.com/c/v8/v8/+/2917612,
but that patch only covered the case where offset_imm == 0.
When there is a non-zero offset, we need the same fix.
Bug: chromium:1224882,v8:11809
Change-Id: I1908f735929798f411346807fc4f3c79d8e04362
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998582
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75500}
Refs: 56fe020eec
Fixes: https://github.com/nodejs/node/issues/39327
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm][liftoff] Always zero-extend 32 bit offsets
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11809
Change-Id: I21e2535c701041d11fa06c176fa683d82db0a3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917612
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74881}
Refs: 2b77ca200c
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[liftoff] Handle constant memory indexes specially
This adds detection for constant memory indexes which can statically be
proven to be in-bounds (because the effective offset is within the
minimum memory size). In these cases, we can skip the bounds check and
the out-of-line code for the trap-handler.
This often saves 1-2% of code size.
R=ahaas@chromium.org
Bug: v8:11802
Change-Id: I0ee094e6f1f5d132af1d6a8a7c539a4af6c3cb5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919827
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74825}
Refs: 53784bdb8f
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
Move DCHECK() in JSCallOrConstructNode ctor into a helper function.
As is, the DCHECK() has a #if inside, and MSVC has trouble
pre-processing that. Fix this by moving the conditional inside the
DCHECK() into a separate helper function.
Bug: v8:11760
Change-Id: Ib4ae0fe263029bb426da378afa5b6881557ce652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74807}
Refs: 7ff6609a53
PR-URL: https://github.com/nodejs/node/pull/38990
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
Mark Node::opcode() and Operator::opcode() as constexpr.
Without the explicit constexpr keyword, Clang seems to be able to treat
these methods as constexpr, whereas MSVC will not.
Bug: v8:11760
Change-Id: I9f6492f38fb50dcaf7a4f09da0bd79c0da6a50eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912916
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74791}
Refs: a5cea1bfc3
PR-URL: https://github.com/nodejs/node/pull/38990
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
[wasm-simd] Skip tests which require Simd enabled
These tests require Simd enabled which causes failures
on machines without the support.
They are already skipped on Mips: https://crrev.com/c/2841887
Change-Id: I4b9a9bb3cb208a0e9aa12dc135393bc515ad766e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2927210
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74891}
Refs: 986299250e
PR-URL: https://github.com/nodejs/node/pull/38990
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
[codegen] Move definition of GetRegisterParameter to inline header
This fixes compilation of V8 in Node.js with Visual Studio 2019.
Without this change, MSVC errors with C3779 (a function that returns
'auto' cannot be used before it is defined) on the `static constexpr
auto registers()` method.
Bug: v8:11420
Change-Id: Id545199e2cdc10c8560031fb5950ec1171e5d554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964095
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75173}
Refs: 71e8f8bb3c
PR-URL: https://github.com/nodejs/node/pull/38990
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
ARM64: VRegister::from_code expected to be constexpr
GCC build fails trying to use a non constexpr function from a
constexpr function.
../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-register.h: In member function 'constexpr v8::internal::DoubleRegister v8::internal::wasm::LiftoffRegister::fp() const':
../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-register.h:286:71: error: call to non-'constexpr' function 'static v8::internal::VRegister v8::internal::VRegister::from_code(int)'
286 | return DoubleRegister::from_code(code_ - kAfterMaxLiftoffGpRegCode);
| ^
In file included from ../chromium-92.0.4503.0/v8/src/codegen/register-arch.h:16,
from ../chromium-92.0.4503.0/v8/src/deoptimizer/translation-array.h:8,
from ../chromium-92.0.4503.0/v8/src/objects/code.h:10,
from ../chromium-92.0.4503.0/v8/src/codegen/reloc-info.h:10,
from ../chromium-92.0.4503.0/v8/src/codegen/assembler.h:47,
from ../chromium-92.0.4503.0/v8/src/codegen/assembler-arch.h:8,
from ../chromium-92.0.4503.0/v8/src/codegen/turbo-assembler.h:12,
from ../chromium-92.0.4503.0/v8/src/codegen/macro-assembler.h:8,
from ../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-assembler.h:13,
from ../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-assembler.cc:5:
../chromium-92.0.4503.0/v8/src/codegen/arm64/register-arm64.h:416:20: note: 'static v8::internal::VRegister v8::internal::VRegister::from_code(int)' declared here
416 | static VRegister from_code(int code) {
| ^~~~~~~~~
Bug: chromium:819294
Change-Id: Ia19ea90f3f666702d32c90e147af17dcda7e08a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929805
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/master@{#74889}
Refs: 3d24b3ab8a
PR-URL: https://github.com/nodejs/node/pull/38990
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This should be semver-patch since actual invocation is version
conditional.
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
[testrunner] delete ancient junit compatible format support
Testrunner has ancient support for JUnit compatible XML output.
This CL removes this old feature.
R=mstarzinger@chromium.org,jgruber@chromium.org,jkummerow@chromium.org
CC=machenbach@chromium.org
Bug: v8:8728
Change-Id: I7e1beb011dbaec3aa1a27398a5c52abdd778eaf0
Reviewed-on: https://chromium-review.googlesource.com/c/1430065
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59045}
Refs: bd019bdb72
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
PPC/s390: [wasm][liftoff] Always zero-extend 32 bit offsets
Port 2b77ca200c56667c68895e49c96c10ff77834f09
Original Commit Message:
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ife3ae4f93b85fe1b2c76fe4b98fa408b5b51ed71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929661
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74886}
Refs: 3805a698f7
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm][arm64] Always zero-extend 32 bit offsets, for realz
We've already been zero-extending 32-bit offset registers since
https://chromium-review.googlesource.com/c/v8/v8/+/2917612,
but that patch only covered the case where offset_imm == 0.
When there is a non-zero offset, we need the same fix.
Bug: chromium:1224882,v8:11809
Change-Id: I1908f735929798f411346807fc4f3c79d8e04362
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998582
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75500}
Refs: 56fe020eec
Fixes: https://github.com/nodejs/node/issues/39327
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[wasm][liftoff] Always zero-extend 32 bit offsets
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11809
Change-Id: I21e2535c701041d11fa06c176fa683d82db0a3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917612
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74881}
Refs: 2b77ca200c
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[liftoff] Handle constant memory indexes specially
This adds detection for constant memory indexes which can statically be
proven to be in-bounds (because the effective offset is within the
minimum memory size). In these cases, we can skip the bounds check and
the out-of-line code for the trap-handler.
This often saves 1-2% of code size.
R=ahaas@chromium.org
Bug: v8:11802
Change-Id: I0ee094e6f1f5d132af1d6a8a7c539a4af6c3cb5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919827
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74825}
Refs: 53784bdb8f
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
Reland "[liftoff][arm64] Use 64 bit offset reg in mem op"
This is a reland of f645d0b857bc669271adcbe95cf25e1554347dd4
The issue was that converting an i64 to an i32 didn't clear the upper
bits on arm64. This was not necessary before because we did the zero
extension as part of the load operand, but this is required now that
we use the full register.
Original change's description:
> [liftoff][arm64] Use 64 bit offset reg in mem op
>
> Accessing the Wasm memory with a 64 bit offset was truncated to 32 bit,
> which is fine if we check bounds first, but not if we rely on the
> trap handler to catch the OOB.
>
> R=clemensb@chromium.org
>
> Bug: v8:11587
> Change-Id: I82a3a2906e55d9d640c30e770a5c93532e3a442c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2808942
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73829}
Bug: v8:11587
Change-Id: Ibc182475745c6f697a0ba6d75c260b74ddf8fe52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2810846
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73853}
Refs: cb4faa902e
PR-URL: https://github.com/nodejs/node/pull/39337
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[runtime] Fix Promise.all context promise hooks
We have to take the slow path in Promise.all if context promise hooks
are set. The fast-path doesn't create intermediate promises by default.
Bug: chromium:1204132, v8:11025
Change-Id: Ide92de00a4f6df05e0ddbc8814f6673bd667f426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2866771
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74326}
Refs: fa4cb172cd
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Original commit message:
[promises] Change context promise hooks to Callable
The previously added perf-context Promise-hooks take a v8::Function as
arguments. However, the builtin code was only accepting JSFunctions
which causes cast errors.
Drive-by-fix: Directly pass nativeContext in more places.
Bug: chromium:1201465
Change-Id: Ic8bed11253a1f18a84e71eb9ea809b1ec1c3f428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850162
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74223}
Refs: 5f44131944
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Original commit message:
Reland "[api] JSFunction PromiseHook for v8::Context"
This is a reland of d5457f5fb7ea05ca05a697599ffa50d35c1ae3c7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
Refs: c0fceaa066
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Original commit message:
PPC: skip all Simd tests on PPC
As of https://crrev.com/c/2629465, Simd tests cannot pass on
architectures without Simd support. Tests will need to be re-enabled
once Simd support is fully implemented on PPC.
Change-Id: I963639f1afa0c0ca7be3ca4b2fc06e874235b903
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2693056
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72788}
Refs: aaacffa1e0
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
There is a bug in the most recent version of VS2015 that affects v8.h
and therefore prevents compilation of addons.
Refs: https://stackoverflow.com/q/38378693
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This should be semver-patch since actual invocation is version
conditional.
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Original commit message:
[testrunner] delete ancient junit compatible format support
Testrunner has ancient support for JUnit compatible XML output.
This CL removes this old feature.
R=mstarzinger@chromium.org,jgruber@chromium.org,jkummerow@chromium.org
CC=machenbach@chromium.org
Bug: v8:8728
Change-Id: I7e1beb011dbaec3aa1a27398a5c52abdd778eaf0
Reviewed-on: https://chromium-review.googlesource.com/c/1430065
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59045}
Refs: bd019bdb72
PR-URL: https://github.com/nodejs/node/pull/32116
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/38273
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
This commit enables FIPS when Node.js is dynamically linking against
quictls/openssl-3.0.
BUILDING.md has been updated with instructions to configure and build
quictls/openssl 3.0.0-alpha-15 and includes a couple of work-arounds
which I believe are fixed in alpha-16 and can be removed when alpha-16
is available. The information might be a little too detailed/verbose
but I thought it would be helpful to at least initially include all the
steps.
PR-URL: https://github.com/nodejs/node/pull/38633
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Original commit message:
[runtime] Fix Promise.all context promise hooks
We have to take the slow path in Promise.all if context promise hooks
are set. The fast-path doesn't create intermediate promises by default.
Bug: chromium:1204132, v8:11025
Change-Id: Ide92de00a4f6df05e0ddbc8814f6673bd667f426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2866771
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74326}
Refs: fa4cb172cd
PR-URL: https://github.com/nodejs/node/pull/36394
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[promises] Change context promise hooks to Callable
The previously added perf-context Promise-hooks take a v8::Function as
arguments. However, the builtin code was only accepting JSFunctions
which causes cast errors.
Drive-by-fix: Directly pass nativeContext in more places.
Bug: chromium:1201465
Change-Id: Ic8bed11253a1f18a84e71eb9ea809b1ec1c3f428
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850162
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74223}
Refs: 5f44131944
PR-URL: https://github.com/nodejs/node/pull/36394
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
Reland "[api] JSFunction PromiseHook for v8::Context"
This is a reland of d5457f5fb7ea05ca05a697599ffa50d35c1ae3c7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
Refs: c0fceaa066
PR-URL: https://github.com/nodejs/node/pull/36394
Reviewed-By: Bryan English <bryan@bryanenglish.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[interpreter] Apply Reflect.apply transform in BytecodeGenerator
Calls with a spread expression in a non-final position get transformed
to calls to Reflect.apply. This transformation is currently done in
the parser, which does not compose well with other features (e.g.
direct eval checking, optional chaining).
Do this transform in the BytecodeGenerator instead.
Bug: v8:11573, v8:11558, v8:5690
Change-Id: I56c90a2036fe5b43e0897c57766f666bf72bc3a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2765783
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73534}
Refs: fd75c97d3f
PR-URL: https://github.com/nodejs/node/pull/38455
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
