Right now util.inspect will always escape single quotes. That is not
necessary though in case the string that will be escaped does not
contain double quotes. In that case the string can simply be wrapped
in double quotes instead.
If the string contains single and double quotes and it does not
contain `${` as part of the string, backticks will be used instead.
That makes sure only very few strings have to escape quotes at all.
Thus it increases the readability of these strings.
PR-URL: https://github.com/nodejs/node/pull/21624
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Remove a couple of obsolete checks by refactoring the code with else.
Also remove the possibility of an undefined warning. That is neither
documented nor does it result in a usable warning.
PR-URL: https://github.com/nodejs/node/pull/20726
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
1) If simple assert is called in the very first line of a file and
it causes an error, it used to report the wrong code. The reason
is that the column that is reported is faulty. This is fixed by
subtracting the offset from now on in such cases.
2) The actual code read is now limited to the part that is actually
required to visualize the call site. All other code in e.g. minified
files will not cause a significant overhead anymore.
3) The number of allocations is now significantly lower than it used
to be. The buffer is reused until the correct line in the code is
found. In general the algorithm tries to safe operations where
possible.
4) The indentation is now corrected depending on where the statement
actually beginns.
5) It is now possible to handle `.call()` and `.apply()` properly.
6) The user defined function name will now always be used instead of
only choosing either `assert.ok()` or `assert()`.
PR-URL: https://github.com/nodejs/node/pull/21626
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
When `writeHeader` of `Http2ServerResponse` instance are called with
204, 205 and 304 status codes an underlying stream closes.
If call `end` method after sending any of these status codes it will
cause an error `TypeError: Cannot read property 'Symbol(trailers)' of
undefined` because a reference to `Http2ServerResponse` instance
associated with Http2Stream already was deleted.
The closing of stream causes emitting `waitTrailers` event and, when
this event handles inside `onStreamTrailerReady` handler, there is
no reference to Http2ServerResponse instance.
Fixes: https://github.com/nodejs/node/issues/21740
PR-URL: https://github.com/nodejs/node/pull/21764
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Add methods that allow inspection of heap snapshots and a JS
version of our own embedder graph.
These can be used in tests and might also prove useful for
ad-hoc debugging. Usage requires `--expose-internals` and
prints a warning similar to our other modules whose primary
purpose is test support.
PR-URL: https://github.com/nodejs/node/pull/21741
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Unused since the excellent refactoring in 2930bd,
which also removed `src/timer_wrap.cc` from `node.gyp`. If you try and
get at the binding on a v11.0-pre build, you'll get an error, since the
file is no longer in the GYP build.
```
Jonathans-MBP:node jon$ ./node -v
v11.0.0-pre
Jonathans-MBP:node jon$ ./node -e "process.binding('timer_wrap')"
internal/bootstrap/loaders.js:81
mod = bindingObj[module] = getBinding(module);
^
Error: No such module: timer_wrap
at process.binding (internal/bootstrap/loaders.js:81:36)
at [eval]:1:9
at Script.runInThisContext (vm.js:89:20)
at Object.runInThisContext (vm.js:286:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at evalScript (internal/bootstrap/node.js:562:27)
at startup (internal/bootstrap/node.js:248:9)
at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)
```
PR-URL: https://github.com/nodejs/node/pull/21777
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Refs: https://github.com/nodejs/node/pull/20894
* set process.exitCode before calling 'exit' handlers so that there will
not be a situation where process.exitCode !== code in 'exit' callback
during uncaughtException handling
* don't ignore process.exitCode set in 'exit' callback when failed with
uncaughtException and there is no uncaughtException listener
PR-URL: https://github.com/nodejs/node/pull/21739
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Proof of concept for an "Edit on GitHub" link, inspired by the
Serverless docs.
One issue is that the link is to the version of the docs on the master
branch even if the person was reading a different version of the doc. I
don't consider that a big problem, although we can always remove the
link if it turns out to be a big problem. I don't think there is a good
solution. PRs need to be opened against the master branch generally.
Having a bunch of PRs against staging branches is probably not what we
want. If there's an update to one version of the doc, there will usually
be an update to other versions.
PR-URL: https://github.com/nodejs/node/pull/21703
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
The regression that test-fs-watch-file-enoent-after-deletion was written
to test for involves whether or not the callback runs or not. Checking
what the file watcher reports unfortunately is subject to race
conditions on Windows (and possibly elsewhere) because the file watcher
returns control to the event loop before it may be receiving data from
the OS. So remove those assertions. The test still checks what it is
supposed to check, but is no longer subject to race conditions.
Fixes: https://github.com/nodejs/node/issues/21692
PR-URL: https://github.com/nodejs/node/pull/21694
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Tobias Nießen