Node codebase has evolved a lot in the more than 10 years of its
existence. As more features (and code) have been added, changed,
removed, it's sometimes hard to keep track of what gets used and what
not.
This commits attempts to clean some of those potentially left-over
headers using suggestions from include-what-you-use
Refs: https://github.com/nodejs/node/issues/27531
PR-URL: https://github.com/nodejs/node/pull/30328
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This can be useful to create `Buffer` instances for already-existing
`ArrayBuffer`s, e.g. ones created manually from a backing store
with a free callback (of which our variant in the public API has
some limitations).
PR-URL: https://github.com/nodejs/node/pull/30476
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Using `ArrayBufferViewContents` over
`Buffer::Data()`/`Buffer::Length()` or `SPREAD_BUFFER_ARG` has the
advantages of creating fewer individual variables to keep track off,
not being a “magic” macro that creates variables, reducing code size,
and being faster when receiving on-heap TypedArrays.
PR-URL: https://github.com/nodejs/node/pull/27920
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`v8::Global` is essentially a nicer variant of `node::Persistent` that,
in addition to reset-on-destroy, also implements move semantics.
This commit makes the necessary replacements, removes
`node::Persistent` and (now-)unnecessary inclusions of the
`node_persistent.h` header, and makes some of the functions that
take Persistents as arguments more generic so that they work with all
`v8::PersistentBase` flavours.
PR-URL: https://github.com/nodejs/node/pull/27287
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This condition was incorrect. We currently take the fallback
path in default Node builds, which always works, but may come with
some overhead, whereas the intention was that we use the fast path
in this condition.
This is causing issues for embedders, because we would erroneously
try to take the fast path when they don’t provide a Node.js-style
`ArrayBufferAlloactor`, and crash as a consequence of that.
This also requires us to relax the check in the debugging ArrayBuffer
allocator a bit, because since d117e41e50, 0-sized ArrayBuffers
may actually point to allocations of size 1. Previously, that wasn’t
caught because the fallback path circumvented our ArrayBufferAllocator.
Refs: 84e02b178a (r33116006)
PR-URL: https://github.com/nodejs/node/pull/27174
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Use a RAII approach by default, and make it possible for embedders
to use the `ArrayBufferAllocator` directly as a V8
`ArrayBuffer::Allocator`, e.g. when passing to `Isolate::CreateParams`
manually.
PR-URL: https://github.com/nodejs/node/pull/26525
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Currently the following compiler warnings are generated on Linux:
../src/node_buffer.cc:
In function 'void node::Buffer::{anonymous}::StringSlice(
const v8::FunctionCallbackInfo<v8::Value>&)
[with node::encoding encoding = (node::encoding)1]':
../src/node_buffer.cc:54:20: warning:
'start' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (end < start) end = start;
^~~
../src/node_buffer.cc:50:10: note: 'start' was declared here
size_t start;
^~~~~
This commit initializes start and end to zero to avoid these warnings.
PR-URL: https://github.com/nodejs/node/pull/25665
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
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>
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>
- Always fulfill the `MaybeLocal<>` contract by scheduling an
exception when returning an empty value. This was previously
inconsistent, with no way to know whether an exception was
be scheduled or not in case of failure.
- Make sure that memory is released exactly once in case of
failure. Previously, some exit conditions would have leaked
memory or attempted to free it multiple times.
This should not really affect how `Buffer`s are created by
addons in practice, due to the low frequency with which
these errors would typically occur.
PR-URL: https://github.com/nodejs/node/pull/23939
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Throw an exception instead of crashing when attempting to create
`Buffer` objects from a Context that is not associated with
a Node.js `Environment`.
Possible alternatives for the future might be just returning
a plain `Uint8Array`, or working on providing `Buffer` for all
`Context`s.
PR-URL: https://github.com/nodejs/node/pull/23938
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Add overloads of the error generation/throwing methods
that take an `Isolate*` argument, since the created objects
don’t depend on the `Environment*` in question.
Also, remove `THROW_ERR_OUT_OF_RANGE_WITH_TEXT`, which did the
same thing as `THROW_ERR_OUT_OF_RANGE` in a more convoluted way.
PR-URL: https://github.com/nodejs/node/pull/23879
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Make `Environment::GetCurrent()` return `nullptr` if the current
`Context` is not a Node.js context, and for the relevant usage of
this function, either:
- Switch to the better `GetCurrent(args)` variant
- Turn functions in to no-ops where it makes sense
- Make it a `CHECK`, i.e. an API requirement, where it make sense
- Leave a `TODO` comment for verifying what, if anything, is to be done
PR-URL: https://github.com/nodejs/node/pull/22819
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
