- Remove misleading 'soon' language
- Remove 'temporary limitation' claim
- Clarify that Node.js will not provide polyfills
- Wait for native JavaScript engine support
Refs: https://github.com/nodejs/node/issues/60282
PR-URL: https://github.com/nodejs/node/pull/60288
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
`.github/workflows/tools.yml` creates a temp file `temp-output` in the
workspace, which fails `git status` clean repo check. Also, the GHA
checks out a new branch after the update script.
Removes these checks in the `roll.py` to fix its run on the GHA.
PR-URL: https://github.com/nodejs/node/pull/60277
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jake Yuesong Li <jake.yuesong@gmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This makes sure special properties (such as a byteLength, buffer,
and more) are marked that they are not regular properties. They
are mostly getters, that just seemed even more of a breaking change.
Thus, they just use square brackets for now.
On top of that, it makes inspecting detached DataViews robust.
Inspecting those failed so far.
PR-URL: https://github.com/nodejs/node/pull/60131
Reviewed-By: Jordan Harband <ljharb@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
- Make sure that the vm.Module.evaluate() method is conditionally
synchronous based on the specification. Previously, the returned
promise is unconditionally pending (even for synthetic modules and
source text modules without top-level await) instead of immediately
fulfilled, making it harder to debug as it deviates from the
specified behavior.
- Clarify the synchronicity of this method in the documentation
- Add more tests for the synchronicity of this method.
PR-URL: https://github.com/nodejs/node/pull/60205
Refs: https://github.com/nodejs/node/issues/59656
Refs: https://github.com/nodejs/node/issues/37648
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously for each matching test, it would execute multiple
`node -p` commands to decide the configurations of the executable.
That means if there are 100 tests matched, it will run the Node.js
executable 4*100 times to retrieve the same configurations repeatedly.
This changes the loop order so that it only execute these commands
once and reuse the results for all matching tests.
PR-URL: https://github.com/nodejs/node/pull/60266
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
There can be a race from eagerly shutting down the servers and
severing two pipes at the same time but for the purpose of this test,
we only care about whether the requests are initiated from the client
as expected, not how the upstream/proxy servers behave. Ignore EPIPE
errors from them.
PR-URL: https://github.com/nodejs/node/pull/60269
Refs: https://github.com/nodejs/node/issues/59741
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
It previously re-einvented the pattern matching that's already
supported by test.py, and was running the tests one by one,
which can lead to time out on slower machines.
This move it to sequential and use wildcard
support in test.py to correctly parallelize the tests.
PR-URL: https://github.com/nodejs/node/pull/60273
Fixes: https://github.com/nodejs/node/issues/60268
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Also add functions as allowed message input.
This allows to have leavy message computation to become cheaper.
PR-URL: https://github.com/nodejs/node/pull/58849
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This seems to be a underdocumented but useful trick that only very few
people know about. Also add a pointer to the test running guide in
the test writing guide.
PR-URL: https://github.com/nodejs/node/pull/60265
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
It's unlikely that anyone would invest in fixing them on x64 macOS
in the near future, now that x64 macOS is being phased out.
Simply skip them for now.
PR-URL: https://github.com/nodejs/node/pull/60250
Refs: https://github.com/nodejs/node/issues/59553
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
This makes skipping/running these tests easier to manage with a
dedicated test runner that can be tweaked for SEA.
PR-URL: https://github.com/nodejs/node/pull/60250
Refs: https://github.com/nodejs/node/issues/59553
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
This lays the initial groundwork for enabling the
use of IsolateGroups.
Every isolate in V8 is created within a group. When pointer
compression is enabled, all isolates within a single group
are limited to a 4 GB shared pointer cage. By default, all
isolates in the process share the same group, which means
that when running with pointer compression, the entire
process would be limited to a single 4 GB shared pointer
cage. But, we can create as many IsolateGroups as we want,
limited only by the amount of virtual memory available on
the machine.
PR-URL: https://github.com/nodejs/node/pull/60254
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
We should be using our own helpers for this instead.
PR-URL: https://github.com/nodejs/node/pull/60244
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Edy Silva <edigleyssonsilva@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ilyas Shabi <ilyasshabi94@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com>
Our own helper classes have the advantage of using stack storage
a lot of the time, so they should always be preferred.
PR-URL: https://github.com/nodejs/node/pull/60244
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Edy Silva <edigleyssonsilva@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ilyas Shabi <ilyasshabi94@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com>
PR-URL: https://github.com/nodejs/node/pull/60245
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Original commit message:
[api] Add index-based module resolution in InstantiateModule()
Add new InstantiateModule() overload that allows embedders to identify
modules requests by index in the module requests array rather than
using specifier and import attributes. When embedders want to fetch
all the modules using information from module->GetModuleRequests()
before calling InstantiateModule() instead of having to do the fetching
inside the InstantiateModule() callback, they could just maintain a simple array of modules indexed by module request positions and
look up the fetched the module by index in the new callback.
Previously this has to be done by mapping from specifier and import
attributes to module objects cached on the embedder side, leading to an overhead to hash the specifier and import attributes for each module request.
Refs: https://github.com/nodejs/node/pull/59396
Bug: 435317398
Change-Id: Ie017d2f3ccc605e0f58aa423504b5fa5fdbcc633
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6804466
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#102613}
Refs: 3d0f462a17
PR-URL: https://github.com/nodejs/node/pull/59396
Refs: https://chromium-review.googlesource.com/c/v8/v8/+/6804466
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Signed-off-by: RafaelGSS <rafael.nunu@hotmail.com>
Co-Authored-By: RafaelGSS <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/59778
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Fixes the constructor name in the stack tree for _errnoException.
PR-URL: https://github.com/nodejs/node/pull/60156
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/60208
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/60209
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Original commit message:
[segmented-table] Disable segments pool if pages can be too large
The segments pool can only be used if we have 16Kb allocation
granularity. On OSs where the page size can be configured larger we have
to disable it, since it is currently not runtime configurabe.
Fixed: 425634685
Change-Id: If77e46b034fc2e324d7eabf19eff54958ea6f7cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6973467
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#102700}
Refs: 1e190bbb03
PR-URL: https://github.com/nodejs/node/pull/60206
Fixes: https://github.com/nodejs/build/issues/4172
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
