The PR template should include a Reference isssue (Fixes #issue_number)
so the PR can be tracked back to the issue easily.For a beginner trying
to read PRs to become comfortable with the codebase,it is really helpful
if one can directly reach the issue the PR fixes.
Fixes: https://github.com/nodejs/node/issues/36338
PR-URL: https://github.com/nodejs/node/pull/36440
Reviewed-By: James M Snell <jasnell@gmail.com>
Add missing 's' to example URL.
PR-URL: https://github.com/nodejs/node/pull/36147
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Harshitha K P <harshitha014@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Be explicit about using `global.externalizeString()` etc. in
test-fs-write instead of disabling the `no-undef` ESLint rule.
PR-URL: https://github.com/nodejs/node/pull/36498
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/36278
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
The test has not failed in quite some time (as far as I can tell) on CI.
Optimistically removing it.
Refs: https://github.com/nodejs/node/pull/29889
PR-URL: https://github.com/nodejs/node/pull/36496
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Fixes running npm tests with `make test-npm`
PR-URL: https://github.com/nodejs/node/pull/36369
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Make sure that `SharedArrayBuffer`s can be deserialized on multiple
receiving ends. As a drive-by, also fix the condition of the
internal assertion that should occur if there are transferables
passed to multiple destinations.
PR-URL: https://github.com/nodejs/node/pull/36501
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Instead of looping through a list of typed arrays, use
TypedArrayPrototypeGetSymbolToStringTag.
PR-URL: https://github.com/nodejs/node/pull/36466
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Fall back to using the outer context’s microtask queue, rather than
the Isolate’s default one. This would otherwise result in surprising
behavior if an embedder specified a custom microtask queue for the
main Node.js context.
PR-URL: https://github.com/nodejs/node/pull/36482
Refs: 4bf051d536
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Original commit message:
[api] Add Context::GetMicrotaskQueue method
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Refs: 4bf051d536
PR-URL: https://github.com/nodejs/node/pull/36482
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Add a way to get the current `IsolateData*` and, from it, the current
Node.js `ArrayBufferAllocator` if there is one. This can be useful
for re-using either one of these structures as an embedder.
PR-URL: https://github.com/nodejs/node/pull/36441
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/36448
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
We have a few places where we individually forward each
parameter to tls.createSecureContext(). In #28973 and others,
we added new SecureContext options but forgot to keep these
places up to date.
As per https.Agent#getName, I understand that at least
`privateKeyIdentifier` and `privateKeyEngine` should be
added too, since they're a substitute for `key`. I've
also added sigalgs.
Fixes: https://github.com/nodejs/node/issues/36322
Refs: https://github.com/nodejs/node/pull/28973
PR-URL: https://github.com/nodejs/node/pull/36416
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/36361
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Node.js sets a stack trace handler specific to the v8::Context
corresponding to the current Environment. When Electron is running in a
non-Node.js v8::Context (e.g in the renderer process with
contextIsolation enabled), there will be no correspondent Environment -
we therefore need to prevent this handler being set so that Blink falls
back to its default handling and displays the correct stacktrace.
PR-URL: https://github.com/nodejs/node/pull/36447
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This test proves that the PerformanceObserver callback gets called with
the async context of the callsite of performance.mark()/measure() and
therefore AsyncLocalStorage can be used inside a PerformanceObserver.
PR: https://github.com/nodejs/node/pull/36343
PR-URL: https://github.com/nodejs/node/pull/36343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This reverts commit 009e41826f.
AFAIU the discussion at [1], PerformanceObserver had been made to
inherit from AsyncResource more or less as a band-aid in lack of a
better async_context candidate to invoke it in. In order to enable
access to AsyncLocalStores from PerformanceObservers invoked
synchronously through e.g. measure() or mark(), the current
async_context, if any, should be retained.
Note that this is a breaking change, but
- as has been commented at [1], PerformanceObserver being derived from
AsyncResource is a "minor divergence from the spec" anyway,
- to my knowledge this is an internal implementation detail which has
never been documented and
- I can't think of a good reason why existing PerformanceObserver
implementations would possibly rely on it.
OTOH, it's probably worthwhile to not potentially invoke before() and
after() async_hooks for each and every PerformanceObserver notification.
[1] https://github.com/nodejs/node/pull/18789
Co-Authored-By: ZauberNerd <zaubernerd@zaubernerd.de>
PR-URL: https://github.com/nodejs/node/pull/36343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
It's desirable to retain async_contexts active at callsites of
perf_hooks.performance.mark() and alike in the subsequent
PerformanceObserver invocations such that the latter can access e.g.
associated AsyncLocalStorage instances.
In working towards this goal replace the node::MakeCallback(...,
async_context{0, 0}) in PerformanceEntry::doNotify() by the new
node::MakeSyncCallback() introduced specifically for this purpose.
This change will retain the original async_context, if any, in
perf_hook's observersCallback() and thus, for the subsequent doNotify()
on unbuffered PerformanceObservers.
Co-Authored-By: ZauberNerd <zaubernerd@zaubernerd.de>
PR-URL: https://github.com/nodejs/node/pull/36343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
There are situations where one wants to invoke a JS callback's ->Call()
from C++ and in particular retain any existing async_context state, but
where it's not obvious that a plain ->Call() would be safe at the point
in question.
Such callsites usually resort to
node::MakeCallback(..., async_context{0, 0}), which unconditionally
pushes the async_context{0, 0} and takes the required provisions for the
->Call() itself such as triggering the tick after its return, if needed.
An example would be the PerformanceObserver invocation from
PerformanceEntry::Notify(): this can get called when coming from JS
through e.g. perf_hooks.performance.mark() and alike, but perhaps also
from nghttp2 (c.f. EmitStatistics() in node_http2.cc).
In the former case, a plain ->Call() would be safe and it would be
desirable to retain the current async_context so that
PerformanceObservers can access it resp. the associated
AsyncLocalStorage. However, in the second case the additional provisions
taken by node::MakeCallback() might potentially be strictly required.
So PerformanceEntry::Notify() bites the bullet and invokes the
PerformanceObservers through node::MakeCallback() unconditionally,
thereby always rendering any possibly preexisting async_context
inaccessible.
Introduce the convenience node::MakeSyncCallback() for such usecases,
which would basically forward to ->Call() if safe and to
node::MakeCallback(..., async_context{0, 0}) otherwise.
Co-Authored-By: ZauberNerd <zaubernerd@zaubernerd.de>
PR-URL: https://github.com/nodejs/node/pull/36343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This commit adds a typedef for the callback parameter used in
CleanupHookCallback's constructor, AddCleanupHook, and
RemoveCleanupHook.
PR-URL: https://github.com/nodejs/node/pull/36442
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Signed-off-by: Michael Dawson <mdawson@devrus.com>
PR-URL: https://github.com/nodejs/node/pull/36475
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Verify that if something different than Abortcontroller.signal is passed
to child_process.execFile(), ERR_INVALID_ARG_TYPE is thrown.
PR-URL: https://github.com/nodejs/node/pull/36429
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/36436
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>