Currently, there is a new popup asking to accept incoming connections
for openssl-cli when running tests on macos. I believe the reason
for this not being noticed before is that test-tls-securepair-client.js
was moved recently from the pummel directory to sequential.
This commit adds openssl-cli to the firewall script.
PR-URL: https://github.com/nodejs/node/pull/25385
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
test-http-client-reconnect-bug depends on `http.createClient()` which
was removed in Node.js 7.0.0. The test was added way back in commit
30b0522157 for a bug fixed in Node.js
0.1.27 in early 2010. We've apparently been fine with it failing since
at least Node.js 7.0.0 which at this time is more than 2 years ago.
Remove this test.
PR-URL: https://github.com/nodejs/node/pull/25387
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Instead of exposing the Buffer prototype methods through an
object in `internal/buffer.js` and then iterating over it
to put the methods on the prototype, create a function
in `internal/buffer.js` to do this.
Also moves the creaton of the `FastBuffer` class into
`internal/buffer.js` and expose it directly instead of
writing it onto that module later.
PR-URL: https://github.com/nodejs/node/pull/25292
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Instead of exposing it in `lib/internal/buffer.js` after deleting
it from the binding and then do the initialization in
`lib/buffer.js`, which results in an implicit dependency on
the order in which these modules are loaded.
PR-URL: https://github.com/nodejs/node/pull/25292
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
test-fs-watch-file.js fails for two reasons. First, there are cases
where it is checking the error message for an error whose message has
changed since the test was written. Change these instances to check for
an error code instead.
Second, there is an instance where it tries to remove a listener but
fails because `common.mustNotCall()` returns a differnet instance of a
function on each call. Store the function in a variable name so it can
be removed as a listener on a file.
PR-URL: https://github.com/nodejs/node/pull/25384
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
https://github.com/nodejs/node/pull/25213 proposes setting umask in the
Python test runner to avoid spurious test failures when running from a
shell with a restrictive umask. This is a good idea, but will only fix
the issue for tests run with the Python runner. Set it in
`common/index.js` as well so that it fixes it even when tests are run
directly with a `node` binary, bypassing the Python test runner.
PR-URL: https://github.com/nodejs/node/pull/25229
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The `actual` and `expected` properties on an instance of
`AssertionError` is now a getter to prevent inspecting these when
inspecting the error. These values will be visible in the error
message and showing them otherwise would decrease the readability
of the error.
PR-URL: https://github.com/nodejs/node/pull/25250
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
The current API is somewhat confusing at times and simpler usage is
possible. This overloads the arguments further to accept objects
with deprecation codes as property keys. It also adds documentation
for the different possible styles.
Besides that it is now going to validate for the code being present
in case of deprecations but not for other cases. The former validation
was not consistent as it only validated some cases and accepted
undefined instead of `common.noWarnCode`. This check is removed due to
the lack of consistency. `common.noWarnCode` is completely removed
due to just being sugar for `undefined`.
This also verifies that the warning order is identical to the order
in which they are triggered.
PR-URL: https://github.com/nodejs/node/pull/25251
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Having an experimental feature behind a flag makes change
if we are expecting significant breaking changes to its API.
Since the Worker API has been essentially stable since
its initial introduction, and no noticeable doubt about
possibly not keeping the feature around has been voiced,
removing the flag and thereby reducing the barrier to experimentation,
and consequently receiving feedback on the implementation,
seems like a good idea.
PR-URL: https://github.com/nodejs/node/pull/25361
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: Shingo Inoue <leko.noor@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Masashi Hirano <shisama07@gmail.com>
Reviewed-By: Weijia Wang <starkwang@126.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
test-uv-threadpool-schedule has been failing consistently in
node-daily-master CI. It also fails consistently on my personal laptop.
These changes make it pass consistently with current master but fail
consistently with Node.js 10.11 (which was the last release in the 10.x
line before the fix that the test is for). It succeeds/fails as expected
whether or not I am connected to the network.
Fixes: https://github.com/nodejs/node/issues/25305
PR-URL: https://github.com/nodejs/node/pull/25358
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
So that it's easier to tell whether we are manipulating per-process
global states that may need to be treated with care to avoid races.
Also added comments about these variables and moved some of them
to a more suitable compilation unit:
- Move `v8_initialized` to `util.h` since it's only used in
`util.cc` and `node.cc`
- Rename `process_mutex` to `tty_mutex` and move it into
`node_errors.cc` since that's the only place it's used
to guard the tty.
- Move `per_process_opts_mutex` and `per_process_opts`
into `node_options.h` and rename them to
`per_process::cli_options[_mutex]`
- Rename `node_isolate[_mutex]` to `per_process::main_isolate[_mutex]`
PR-URL: https://github.com/nodejs/node/pull/25302
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
