This makes sure that the `add` function is not visible by default
when inspecting `process.allowedNodeEnvironmentFlags`.
PR-URL: https://github.com/nodejs/node/pull/28206
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Use the common `.then(common.mustCall())` check to verify that.
Also, we should not use `process.abort()` in `test/parallel`; if
the test fails, that leaves core dumps lying around on POSIX systems.
PR-URL: https://github.com/nodejs/node/pull/28155
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Simplify language, remove redundancy ("tests that can be used to
test") and remove wordy passive voice ("that can be used to" replaced
with "for").
PR-URL: https://github.com/nodejs/node/pull/28226
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit removes what looks like an unnecessary setting of
exports.DEFAULT_MAX_VALUE.
PR-URL: https://github.com/nodejs/node/pull/28147
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
At the collaborator summit in Berlin, the behaviour of
`worker.terminate()` was discussed.
In particular, switching from a callback-based to a Promise-based API
was suggested. While investigating that possibility later, it was
discovered that `.terminate()` was unintentionally synchronous up
until now (including calling its callback synchronously).
Also, the topic of its stability has been brought up. I have performed
two manual reviews of the native codebase for compatibility with
`.terminate()`, and performed some manual fuzz testing with the test
suite. At this point, bugs with `.terminate()` should, in my opinion,
be treated like bugs in other Node.js features.
(It is possible to make Node.js crash with `.terminate()` by messing
with internals and/or built-in prototype objects, but that is already
the case without `.terminate()` as well.)
This commit:
- Makes `.terminate()` an asynchronous operation.
- Makes `.terminate()` return a `Promise`.
- Runtime-deprecates passing a callback.
- Removes a warning about its stability from the documentation.
- Eliminates an unnecessary extra function from the C++ code.
A possible alternative to returning a `Promise` would be to keep the
method synchronous and just drop the callback. Generally, providing
an asynchronous API does provide us with a bit more flexibility.
Refs: https://github.com/nodejs/summit/issues/141
PR-URL: https://github.com/nodejs/node/pull/28021
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Stop automatically setting servername in https.request() if the target
host is specified with an IP address. Doing so is invalid, and triggers
a deprecation warning. It is still possible to send an IP address as a
servername if its required, but it needs to be explicity configured, it
won't happen automatically.
PR-URL: https://github.com/nodejs/node/pull/28209
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
After an OpenSSL source update, all the config files need to be
regenerated and comitted by:
$ cd deps/openssl/config
$ make
$ git add deps/openssl/config/archs
$ git add deps/openssl/openssl/crypto/include/internal/bn_conf.h
$ git add deps/openssl/openssl/crypto/include/internal/dso_conf.h
$ git add deps/openssl/openssl/include/openssl/opensslconf.h
$ git commit
PR-URL: https://github.com/nodejs/node/pull/28211
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Shigeki Ohtsu <ohtsu@ohtsu.org>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Document why the dates are calculated with the timestamp
in Numbers + 0.5.
The comment was previously lost in a revert.
Refs: ae6c7044c8
PR-URL: https://github.com/nodejs/node/pull/28224
Refs: ae6c7044c8
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Conditionally build `test/cctest/test_report_util.cc` only when
configured to include the diagnostic report feature.
PR-URL: https://github.com/nodejs/node/pull/28238
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This improves a couple minor things:
* Arrays that contain entries other than `number` or `bigint` are
ordered to the left instead of the right.
* The bias towards more columns got increased. That mainly increases
the number of columns for arrays that contain lots of short entries.
* Columns are now more dense in case they would otherwise have extra
whitespace in-between two columns.
* The maximum columns got increased from 10 to 15.
* The maximum number of columns per `compact` was increased from
3 to 4.
PR-URL: https://github.com/nodejs/node/pull/28070
Refs: https://github.com/nodejs/node/issues/27690
Reviewed-By: James M Snell <jasnell@gmail.com>
The configuration variable being tested is `true` if Node.js was
compiled without support for NODE_OPTIONS.
PR-URL: https://github.com/nodejs/node/pull/28225
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Simplify and clarify introductory material on `strict` mode.
Merge two single-sentence paragraphs into a single paragraph.
Replace "`strict mode`" with "`strict` mode".
PR-URL: https://github.com/nodejs/node/pull/28239
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently, when configuring --without-ssl the test-doc target fails with
the following error:
/node/test/common/index.js:707
const crashOnUnhandledRejection = (err) => { throw err; };
^
Error [ERR_NO_CRYPTO]:
Node.js is not compiled with OpenSSL crypto support
at Object.assertCrypto (internal/util.js:97:11)
at https.js:26:26
at NativeModule.compile (internal/bootstrap/loaders.js:300:5)
...
at /node/tools/doc/versions.js:7:19
at new Promise (<anonymous>)
at getUrl (/node/tools/doc/versions.js:6:10)
Command: out/Release/node /node/test/doctool/test-doctool-html.js
[00:02|% 100|+ 3|- 1]: Done
make: *** [test-doc] Error 1
This commit guards the test-doc recipe to not run if node was
configured without crypto support.
PR-URL: https://github.com/nodejs/node/pull/28199
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
- Use constants instead of a dictionary and add comments
about the behavior of each mode.
- Use switch cases to handle the unhandled rejection modes.
- Rename the run time value of the CLI option from `state`
to `unhandledRejectionsMode`.
- Return in the call site of `emitWarning` when
`--unhandled-rejections=none` instead of inside
the function.
PR-URL: https://github.com/nodejs/node/pull/28228
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Historically `error.errno` of system errors thrown by Node.js
can sometimes be the same as `err.code`, which are string
representations of the error numbers. This is useless and incorrect,
and results in an information loss for users since then they
will have to resort to something like
`process.binding('uv'[`UV_${errno}`])` to get to the numeric
error codes.
This patch corrects this behavior by always setting `error.errno`
to be negative numbers. For fabricated errors like `ENOTFOUND`,
`error.errno` is now undefined since there is no numeric equivalent
for them anyway. For c-ares errors, `error.errno` is now undefined
because the numeric representations (negated) can be in conflict
with libuv error codes - this is fine since numeric codes was
not available for c-ares errors anyway.
Users can use the public API `util.getSystemErrorName(errno)`
to retrieve string codes for these numbers.
PR-URL: https://github.com/nodejs/node/pull/28140
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This patch re-enables custom V8 snapshot integration. Also renames
the experimental configure switch from `--with-node-snapshot`
to `--without-node-snapshot` to be consistent with`--without-snapshot`
which is used for the default V8 snapshot.
PR-URL: https://github.com/nodejs/node/pull/28181
Refs: https://github.com/nodejs/node/pull/27365
Refs: https://github.com/nodejs/node/issues/17058
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The tests still fail after being split into multiple files,
(2 out of 30 runs in roughly 48 hours) and the causes are missing
target frames in the samples. This patch moves them to sequential
to observe if the flakiness can be fixed when the tests are
run on a system with less load.
If the flake ever shows up again even after the tests are moved
to sequential, we should consider make the test conditions more
lenient - that is, we would only assert that there are *some* frames
in the generated CPU profile but do not look for the target
function there.
PR-URL: https://github.com/nodejs/node/pull/28210
Refs: https://github.com/nodejs/node/issues/27611
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
There is no need to use loose equality on these checks because
undefined is caught by the preceding typeof check.
PR-URL: https://github.com/nodejs/node/pull/28166
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Currently, when configuring --without-ssl the following compiler warning
is generated:
../src/node_worker.cc:192:10:
warning: unused variable 'inspector_started' [-Wunused-variable]
bool inspector_started = false;
^
1 warning generated.
This commit adds a macro guard to the variable to avoid the warning.
PR-URL: https://github.com/nodejs/node/pull/28198
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The report shows CPU consumption %, but without the number of CPU cores,
a consumer cannot tell if the percent (given across all cores) is
actually problematic. E.g., 100% on one CPU is a problem, but 100% on
four CPUs is not necessarily.
This change adds CPU information (similar to `os.cpus()`) to the report
output. Extra info besides the count is also provided as to avoid future
breaking changes in the eventuality that someone needs it; changing the
datatype of `header.cpus` would be breaking.
PR-URL: https://github.com/nodejs/node/pull/28188
Refs: https://github.com/nodejs/diagnostics/issues/307
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This checks if any require calls have happened to the same file
during the file read. If that was the case, it'll return the same
module instead of creating a new instance.
PR-URL: https://github.com/nodejs/node/pull/27674
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Add a test that checks that the documented allowed options for the
`NODE_OPTIONS` environment variable are consistent with the actually
allowed options.
PR-URL: https://github.com/nodejs/node/pull/28179
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Add missing options to the list of allowed options for the
`NODE_OPTIONS` environment variable. Sort the list alphabetically.
PR-URL: https://github.com/nodejs/node/pull/28179
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Include directories are configured by the tools/icu/icu-*.gyp files.
The v8.gyp file doesn't need to add them and in fact the way it did
that breaks when building against an external copy of ICU.
Fixes: https://github.com/nodejs/node/issues/28052
PR-URL: https://github.com/nodejs/node/pull/28118
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The pkg_config() helper can either return a tuple of None values
(no pkg-config installed) and that was what the check was testing
for, but it can also return a tuple of empty strings when the
package isn't installed.
PR-URL: https://github.com/nodejs/node/pull/28118
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/28118
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Due to a bug in V8 GC, this test case has to potential to fail
on all platforms. V8 master has been patched with a fix and waiting
for it to be backported to V8 7.5 and 7.6. Skipping the test until
it is backported. Bug can be tracked here:
https://bugs.chromium.org/p/v8/issues/detail?id=9333
PR-URL: https://github.com/nodejs/node/pull/28175
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Without this, we would re-enter the signal handler immediately
after re-raising the signal, leading to an infinite loop.
PR-URL: https://github.com/nodejs/node/pull/27775
Refs: https://github.com/nodejs/node/pull/27246
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This macro is only defined when building Node.js, so addons cannot
use it as a way of detecting feature availability.
PR-URL: https://github.com/nodejs/node/pull/27775
Refs: https://github.com/nodejs/node/pull/27246
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Fixes: https://github.com/nodejs/node/issues/28159
PR-URL: https://github.com/nodejs/node/pull/28163
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.
However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.
This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.
Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.
Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.
Fixes: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/28082
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.
PR-URL: https://github.com/nodejs/node/pull/28082
Fixes: https://github.com/nodejs/node/issues/26754
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
We've moved master to build on centos7 for PPCle, adjust
the glibc and kernel levels accordingly.
PR-URL: https://github.com/nodejs/node/pull/28162
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
- Extend the aliased buffer for stats objects to contain
the entire time spec (seconds and nanoseconds) for the time
values instead of calculating the milliseconds in C++ and
lose precision there.
- Calculate the nanosecond-precision time values in JS and expose
them in BigInt Stats objects as `*timeNs`. The
millisecond-precision values are now calculated from the
nanosecond-precision values.
PR-URL: https://github.com/nodejs/node/pull/21387
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
