- Mar 03, 2019
-
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26273 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Tobias Nießen <tniessen@tnie.de> Reviewed-By:
Luigi Pinca <luigipinca@gmail.com>
-
Rich Trott authored
Update `extend` to 3.0.2 as 3.0.1 is susceptible to a low-severity security issue. Refs: https://snyk.io/vuln/npm:extend:20180424 PR-URL: https://github.com/nodejs/node/pull/26392 Reviewed-By:
Masashi Hirano <shisama07@gmail.com> Reviewed-By:
-
Rich Trott authored
Remove entries from `.gitignore` that are already covered by the generic `.*` entry on line 2 of the .gitignore file. PR-URL: https://github.com/nodejs/node/pull/26370 Reviewed-By:
Refael Ackermann <refack@gmail.com> Reviewed-By:
-
cjihrig authored
This commit completes the renaming of node-report to report in order to better differentiate core's reporting from the node-report npm module. PR-URL: https://github.com/nodejs/node/pull/26371 Reviewed-By:
Rich Trott <rtrott@gmail.com> Reviewed-By:
Minwoo Jung <minwoo@nodesource.com> Reviewed-By:
-
cjihrig authored
This commit renames the "node-report" test suite to "report" in order to begin differentiating core's diagnostic reporting from the original node-report module on npm PR-URL: https://github.com/nodejs/node/pull/26371 Reviewed-By:
-
cjihrig authored
This commit improves the validation of generated diagnostic reports. PR-URL: https://github.com/nodejs/node/pull/26289 Reviewed-By:
-
Matteo Collina authored
This change adds a EventEmitter.once() method that wraps ee.once in a promise. Co-authored-by:
David Mark Clements <david.mark.clements@gmail.com> PR-URL: https://github.com/nodejs/node/pull/26078 Reviewed-By:
Gus Caplan <me@gus.host> Reviewed-By:
Michaël Zasso <targos@protonmail.com> Reviewed-By:
Anatoli Papirovski <apapirovski@mac.com> Reviewed-By:
Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By:
Сковорода Никита Андреевич <chalkerx@gmail.com>
-
- Mar 02, 2019
-
-
Sebastiaan Deckers authored
PR-URL: https://github.com/nodejs/node/pull/26309 Reviewed-By:
Matteo Collina <matteo.collina@gmail.com> Reviewed-By:
-
Beni von Cheni authored
PR-URL: https://github.com/nodejs/node/pull/26312 Reviewed-By:
Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By:
-
Rich Trott authored
Update babel-eslint to 10.0.1. PR-URL: https://github.com/nodejs/node/pull/26347 Reviewed-By:
Shingo Inoue <leko.noor@gmail.com> Reviewed-By:
-
Ben Noordhuis authored
Downgrade the 'Using floating patch' message that is emitted when a local patch is applied to the bundled ICU from a warning to a notice. There isn't anything the user can or should do so warning isn't appropriate. Instead of angry yellow use soothing green. Fixes: https://github.com/nodejs/node/issues/26346 PR-URL: https://github.com/nodejs/node/pull/26349 Reviewed-By:
-
Anna Henningsen authored
Provide `process.execArgv`. If an `execArgv` option is passed to the `Worker` constructor, that option is used as its value; if not, the parent’s `process.execArgv` is inherited (since that also goes for the actual options in that case). PR-URL: https://github.com/nodejs/node/pull/26267 Reviewed-By:
Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By:
-
Tobias Nießen authored
PR-URL: https://github.com/nodejs/node/pull/26249 Reviewed-By:
Sam Roberts <vieuxtech@gmail.com> Reviewed-By:
-
Rich Trott authored
For eslint-plugin-markdown, we had been using an RC but can now use the most recent stable release of 1.0.0, as it has the bugfix that caused us to start using the RC in the first place. There are a few other updates in this commit too because it was performed by running `update-eslint.sh`. This did not update ESLint itself but did update some dependencies. PR-URL: https://github.com/nodejs/node/pull/26345 Reviewed-By:
-
Rich Trott authored
eslint-plugin-markdown is being installed @next to get a bugfix for https://github.com/eslint/eslint-plugin-markdown/issues/69 but that bugfix is in 1.0.0. Go back to installing @latest rather than @next. PR-URL: https://github.com/nodejs/node/pull/26345 Reviewed-By:
-
Luigi Pinca authored
PR-URL: https://github.com/nodejs/node/pull/26152 Reviewed-By:
-
Luigi Pinca authored
PR-URL: https://github.com/nodejs/node/pull/26152 Reviewed-By:
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26204 Reviewed-By:
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26242 Reviewed-By:
-
Thomas authored
Ref: https://github.com/nodejs/node/issues/25987 PR-URL: https://github.com/nodejs/node/pull/26096 Refs: https://github.com/nodejs/node/issues/25987 Reviewed-By:
Gabriel Schulhof <gabriel.schulhof@intel.com>
-
Richard Lau authored
Attempt to report the host and port in the case that uv_getnameinfo() fails. PR-URL: https://github.com/nodejs/node/pull/26140 Reviewed-By:
-
Anna Henningsen authored
Unlike `node::Persistent`, `v8::Global` has move semantics and can be used directly in STL containers. PR-URL: https://github.com/nodejs/node/pull/26254 Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
-
Anna Henningsen authored
- Prefer RAII-style management over manual resource management. - Prefer `env->SetImmediate()` over a separate `uv_async_t`. - Perform `ares_destroy()` before possibly tearing down c-ares state. - Verify that the number of active queries is non-negative. - Let pending callbacks know when their underlying `QueryWrap` object has been destroyed. The last item has been a real bug, in that when Workers shut down during currently running DNS queries, they may run into use-after-free situations because: 1. Shutting the `Worker` down leads to the cleanup code deleting the `QueryWrap` objects first; then 2. deleting the `ChannelWrap` object (as it has been created before the `QueryWrap`s), whose destructor runs `ares_destroy()`, which in turn invokes all pending query callbacks with `ARES_ECANCELLED`, 3. which lead to use-after-free, as the callback tried to access the deleted `QueryWrap` object. The added test verifies that this is no longer an issue. PR-URL: https://github.com/nodejs/node/pull/26253 Reviewed-By:
-
Anna Henningsen authored
Check that small typed arrays, including `Buffer`s (unless allocated by `Buffer.allocUnsafe()`), are indeed heap-allocated. PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
-
Anna Henningsen authored
Do not create an `ArrayBuffer` if the engine’s settings avoid it and we don’t need it. PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
-
Anna Henningsen authored
Where appropriate, use a helper that wraps around `ArrayBufferView::Buffer()` or `ArrayBufferView::CopyContents()` rather than `Buffer::Data()`, as that may help to avoid materializing the underlying `ArrayBuffer` when reading small typed arrays from C++. This allows keeping the performance benefits of the faster creation of heap-allocated small typed arrays in many cases. PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
-
Anna Henningsen authored
This was added in 16f86d6c, based on the assumption that otherwise, the memory behind `ArrayBuffer` instances could be moved around on the heap while native code holds references to it. This does not match what V8 actually does (and also did at the time): - The option/build variable was about always only about TypedArrays, not ArrayBuffers. Calls like `new ArrayBuffer(4)` call into C++ regardless of the option value, but calls like `new Uint8Array(4)` would not call into C++ under V8 defaults. - When first accessing a heap-allocated TypedArray’s `ArrayBuffer`, whether that is through the JS `.buffer` getter or the C++ `ArrayBufferView::Buffer()` function, a copy of the contents is created using the ArrayBuffer allocator and stored as the (permanent, unmovable) backing store. As a consequence, the memory returned by `ArrayBuffer::GetContents()` is not moved around, because it is fixed once the `ArrayBuffer` object itself first comes into explicit existence in any way. Removing this build option significantly speeds up creation of typed arrays from JS: $ ./node benchmark/compare.js --new ./node --old ./node-master --runs 10 --filter buffer-creation.js buffers | Rscript benchmark/compare.R confidence improvement accuracy (*) (**) (***) buffers/buffer-creation.js n=1024 len=10 type='buffer()' *** 593.66 % ±28.64% ±41.10% ±60.36% buffers/buffer-creation.js n=1024 len=10 type='fast-alloc-fill' *** 675.42 % ±90.67% ±130.24% ±191.54% buffers/buffer-creation.js n=1024 len=10 type='fast-alloc' *** 663.55 % ±58.41% ±83.87% ±123.29% buffers/buffer-creation.js n=1024 len=10 type='fast-allocUnsafe' 3.10 % ±9.63% ±13.22% ±18.07% buffers/buffer-creation.js n=1024 len=10 type='slow-allocUnsafe' 4.67 % ±5.55% ±7.77% ±10.97% buffers/buffer-creation.js n=1024 len=10 type='slow' -2.48 % ±4.47% ±6.12% ±8.34% buffers/buffer-creation.js n=1024 len=1024 type='buffer()' -1.91 % ±4.71% ±6.45% ±8.79% buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc-fill' -1.34 % ±7.53% ±10.33% ±14.10% buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc' 0.52 % ±5.00% ±6.87% ±9.40% buffers/buffer-creation.js n=1024 len=1024 type='fast-allocUnsafe' 0.39 % ±5.65% ±7.78% ±10.67% buffers/buffer-creation.js n=1024 len=1024 type='slow-allocUnsafe' -0.13 % ±5.68% ±7.83% ±10.77% buffers/buffer-creation.js n=1024 len=1024 type='slow' -5.07 % ±7.15% ±9.80% ±13.35% buffers/buffer-creation.js n=1024 len=2048 type='buffer()' 0.57 % ±2.70% ±3.74% ±5.16% buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc-fill' -1.60 % ±4.96% ±6.79% ±9.25% buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc' 1.29 % ±3.79% ±5.20% ±7.09% buffers/buffer-creation.js n=1024 len=2048 type='fast-allocUnsafe' 2.73 % ±8.79% ±12.05% ±16.41% buffers/buffer-creation.js n=1024 len=2048 type='slow-allocUnsafe' -0.99 % ±6.27% ±8.65% ±11.91% buffers/buffer-creation.js n=1024 len=2048 type='slow' -5.98 % ±6.24% ±8.71% ±12.20% buffers/buffer-creation.js n=1024 len=4096 type='buffer()' -1.75 % ±3.48% ±4.78% ±6.56% buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc-fill' -3.18 % ±3.97% ±5.45% ±7.45% buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc' 2.05 % ±4.05% ±5.58% ±7.65% buffers/buffer-creation.js n=1024 len=4096 type='fast-allocUnsafe' 1.44 % ±5.51% ±7.63% ±10.57% buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' * -4.77 % ±4.30% ±5.90% ±8.06% buffers/buffer-creation.js n=1024 len=4096 type='slow' -3.31 % ±6.38% ±8.86% ±12.34% buffers/buffer-creation.js n=1024 len=8192 type='buffer()' 0.06 % ±2.70% ±3.77% ±5.31% buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc-fill' -1.20 % ±3.30% ±4.53% ±6.17% buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc' -1.46 % ±2.75% ±3.84% ±5.38% buffers/buffer-creation.js n=1024 len=8192 type='fast-allocUnsafe' 1.27 % ±4.69% ±6.49% ±8.98% buffers/buffer-creation.js n=1024 len=8192 type='slow-allocUnsafe' -1.68 % ±3.30% ±4.62% ±6.49% buffers/buffer-creation.js n=1024 len=8192 type='slow' -2.49 % ±3.24% ±4.44% ±6.07% (Re-running the outlier with 30 runs instead of 10:) buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' 2.06 % ±2.39% ±3.19% ±4.15% The performance gains effect are undone once native code accesses the underlying ArrayBuffer, but then again that a) does not happen for all TypedArrays, and b) it should also make sense to look into using `ArrayBufferView::CopyContents()` in some places, which is made specifically to avoid such a performance impact and allows us to use the benefits of heap-allocated typed arrays. Refs: https://github.com/nodejs/node/commit/16f86d6c578ff7aec708c7d736558a199d290e9c Refs: https://github.com/nodejs/node/pull/2893 Refs: https://github.com/nodejs/node/commit/74178a5682958d499896e0fa1af6bc0321ec1935#commitcomment-13250880 Refs: http://logs.libuv.org/node-dev/2015-09-15 PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
-
Anna Henningsen authored
This was overlooked in c5832453. Refs: https://github.com/nodejs/node/pull/26137 PR-URL: https://github.com/nodejs/node/pull/26295 Reviewed-By:
-
Anna Henningsen authored
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly. PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
Gireesh Punathil <gpunathi@in.ibm.com>
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26243 Reviewed-By:
-
cjihrig authored
PR-URL: https://github.com/nodejs/node/pull/26368 Reviewed-By:
Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By:
-
- Mar 01, 2019
-
-
Avi ד authored
Prevents moving left or right from placing the cursor in between code units comprising a code point. PR-URL: https://github.com/nodejs/node/pull/25723 Fixes: https://github.com/nodejs/node/issues/25693 Reviewed-By:
-
Ruben Bridgewater authored
This moves a condition inside of a for loop which can only be triggered at the very end of the for loop outside of the loop. That way the for loop itself is much simpler and easier to understand and the code itself is less indented which should increase the readability. It also refactors some `var` to `let` and `const`. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
This moves the `if (len === 1)` case to the top of the function. That way it is possible to reduce the indentation level due to returning early in that case. On top of that the following was done: 1) For clarity refactored for loops which were meant to count up a variable into a while loop. 2) Used template strings instead of string concat. 3) Consolidating nested if statements. 4) Using tenary expressions if applicable when assigning variables to reduce the code overhead. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
Either `end` is `-1` or `startPart` is not `0`. Therefore it's possible to move the conditions in a way that we eliminate a few code branches. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
This refactoring makes sure some code branches will not be hit if they do not have to be reached. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
1) Consolidate nested if statements if possible `if (foo) { if bar () { /* do stuff */ } }`) to reduce indentation depth. 2) Remove obsolete else cases to reduce indentation. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By: -
Ruben Bridgewater authored
1) Consolidate format to a single function. 2) Move some code that can only be reached in some code branches that was formerly executed in all cases. 3) Explicitly check for the string length of zero instead of converting the string to a boolean. 4) Consolidate nested if statements if possible e.g., if (foo) { if (bar) { /* do stuff */ } } to reduce indentation depth. 5) Simplify checks by removing extra length checks when comparing two strings. 6) Use object shorthand notation where possible. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By: -
Ruben Bridgewater authored
1) Refactor for loops to while loops that were only meant to count up a variable. 2) Refactor some `var` statements to `let` / `const`. 3) Simplify return conditions. 4) Use template strings where possible instead of concat. 5) Use ternary expressions for variable assignments instead of if / else. 6) Use the object shorthand notation for the function declarations. 7) Consolidate if else case where possible. 8) Remove double line breaks. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
