Commit Graph

6 Commits

Author SHA1 Message Date
himself65
1bbd679adc
lib: replace Array to ArrayIsArray by primordials
PR-URL: https://github.com/nodejs/node/pull/32258
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.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: Trivikram Kamat <trivikr.dev@gmail.com>
2020-03-30 10:22:52 +02:00
bcoe
fb26b13623
module: port source map sort logic from chromium
Digging in to the delta between V8's source map library, and chromium's
the most significant difference that jumped out at me was that we were
failing to sort generated columns. Since negative offsets are not
restricted in the spec, this can lead to bugs.

fixes: #31286

PR-URL: https://github.com/nodejs/node/pull/31927
Fixes: https://github.com/nodejs/node/issues/31286
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
2020-02-27 17:33:56 -08:00
Justin Ridgewell
f2ec64fbcf
lib: delete dead code in SourceMap
This seems to be a leftover from the chromium project. Nothing uses
`#reverseMappingsBySourceURL`, so constructing it isn't necessary.

PR-URL: https://github.com/nodejs/node/pull/31512
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2020-01-28 15:29:33 +00:00
Justin Ridgewell
0214b90308 process: fix two overflow cases in SourceMap VLQ decoding
These both have to do with extremely large numbers, so it's unlikely to
cause a problem in practice. Still, correctness.

First, encoding `-2147483648` in VLQ returns the value `"B"`. When
decoding, we get the value `1` after reading the base64. We then check
if the first bit is set (it is) to see if we should negate it, then we
shift all bits right once. Now, `value` will be `0` and `negate` will
be `true`. So, we'd return `-0`. Which is a bug! `-0` isn't
`-2147483648`, and we've broken a round trip.

Second, encoding any number with the 31st bit set, we'd return the
opposite sign. Let's use `1073741824`. Encoding, we get `"ggggggC"`.
When decoding, we get the value `-2147483648` after reading the base64.
Notice, it's already negative (the 32nd bit is set, because the 31st was
set and we shifted everything left once). We'd then check the first bit
(it's not) and shift right. But we used `>>`, which does not shift the
sign bit. We actually wanted `>>>`, which will. Because of that bug, we
get back `-1073741824` instead of the positive `1073741824`. It's even
worse if the 32nd and 31st bits are set, `-1610612736` becomes
`536870912` after a round trip.

I recently fixed the same two bugs in Closure Compiler:
https://github.com/google/closure-compiler/commit/584418eb

PR-URL: https://github.com/nodejs/node/pull/31490
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
2020-01-26 17:03:39 -08:00
bcoe
521b2224c3
module: add API for interacting with source maps
PR-URL: https://github.com/nodejs/node/pull/31132
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2020-01-14 12:39:06 -08:00
bcoe
e1e2f669f6
process: add source-map support to stack traces
PR-URL: https://github.com/nodejs/node/pull/29564
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-10-05 17:08:00 -07:00