... using up-to-date git cl format.

Bug: v8:10155
Change-Id: Ie29b492a7831fe2d7c0de247d16f9b7be9e42a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026730Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66024}

... which didn't check writability of array length on appending
a new element to an array.

Bug: chromium:1041251
Change-Id: I6935e505a4844e5b22abe9d4a42786619499daa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023551Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66023}

This reverts commit 7d1f95d6.

Reason for revert: Speculative revert for https://crbug.com/1046678

Original change's description:
> [regexp] Correctly escape a backslash-newline sequence
> 
> When printing the source string, a backslash-newline sequence ('\\\n',
> '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
> '\u2028', '\u2029', respectively. Prior to this CL it was formatted as
> a backslash followed by the literal newline character.
> 
> Bug: v8:8615
> Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65986}

TBR=neis@chromium.org,jgruber@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:8615,chromium:1046678
Change-Id: If28626a1c6868ed848310c0d30cf61a73326f2c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027452Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66022}

The compiler assumes (for loads) that the property cell of a
non-configurable global property never gets invalidated.

Bug: chromium:1044919
Change-Id: I27f6ce30fb9a21e2c1e5310f25e9bb973ebbc266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023562Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66021}

Converting an object to an array length can freeze the array whose
length is being set, but SetLength for the frozen elements accessor
is supposedly unreachable. This fix extends the existing special
handling for suddenly-readonly lengths to cover this case as well.
Prior art: https://codereview.chromium.org/2543553002

Bug: chromium:1044911
Change-Id: I85d2e79446a8d9c1d22cd86ddf828328bf51a1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023555
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66020}

Currently objects that belong to the untracked contexts (i.e. contexts
for which measurement was not requested) are accounted in the shared
context. This CL introduces a dummy kOtherContext and attributes such
objects to that context.

Bug: chromium:973627
Change-Id: I9801ab317d95b944336b79a5e17721511d4897c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025370Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66019}

The existing legacy performance.memory API accounts external string
and array buffer backing store bytes. This CL adds per-context tracking
of external bytes

Bug: chromium:973627
Change-Id: I2b308dc540454e7b0b66406b83a18bf8f8d55d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025369Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66018}

Put a logic in Wasm Engine to tier down all existing modules per isolate
when debugger is enabled. This CL does not handle new module added after
debugger is enabled yet.

Bug: v8:9654
Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66017}

Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/e327c63..bd79231

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/fd02540..2f17606

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/73414d5..afc5b79

Rolling v8/buildtools/linux64: git_revision:0c5557d173ce217cea095086a9c9610068123503..git_revision:97cc440d84f050f99ff0161f9414bfa2ffa38f65

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/251c765..2e0a0cb

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/05b001c..ea8b58b

Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/94485d9..b9b9a5a

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/42fbdfe..535dbf1

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: Ie4dd3f3acb98c7fd3bbba0d5425a2791bf94567e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027147Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66016}

These conversion instructions were removed from the proposal in
https://github.com/WebAssembly/simd/pull/178.

Change-Id: I212ca2f923362bf08e178f6d28cc2338cf6f5927
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016006Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66015}

R=clemensb@chromium.org

Bug: v8:10108
Change-Id: I1a0546b4a5b754dcf35c66594ac7c5c37d940001
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019484
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66014}

Added the new dependency pointing to head of this repo:
https://chromium.googlesource.com/chromium/src/third_party/android_platform/

A more relevant dry run can be found below where I also included the changes that the auto-roller was unable to land.
https://chromium-review.googlesource.com/c/v8/v8/+/2023553

Bug: chromium:1043646
Change-Id: Ife6547ca9cbb7f303beb48c330d1b4457495dd83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023556Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66013}

Remove include for state-values-utils.h and add node.h and
utils/ostream.h.

Bug: v8:10155
Change-Id: I3662018b546a0a9b82bc2cc72f3a8ced27156fe0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023557
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66012}

Change-Id: I0c85de569b75e47dddb54c2dc4101da252547751
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023370Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66011}

R=clemensb@chromium.org

Bug: v8:10108
Change-Id: I0a561a007ffd5327f47f68cc605b9eae57829d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016596
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66010}

Declare that ByteCodeArray's source_position_table entry can also
contain Exception. (Also adds the Exception type to base.tq).

This is just a clean up for now but could be required if torque starts
generating checks for Union types (including differentiating between
different Oddballs).

Change-Id: Ie34ade100040df2f3a2e8120613b6b29d604984a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019483
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66009}

This CL fixes a parser crash in REPL mode. Some SyntaxErrors can cause
the AST to contain NULL nodes, resulting in a crash when we want to
rewrite the AST after parsing.

Instead of re-writing a broken AST we bail early.

R=leszeks@chromium.org

Bug: chromium:1040034, chromium:1045758
Change-Id: I9c559f6de5969c8db17833ccbdb1608627b46311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023547Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66008}

The current implementation takes forwarding reference arguments, which
is fine when you call it with rvalues, like
make_iterator_range(V.begin(), V.end()). If you call it with lvalues
though, it doesn't do what you'd expect. ForwardIterator becomes a
reference:

Foo I = V.begin();
make_iterator_range(I, I); //ForwardIterator is deduced as Foo&

Since iterator are supposed to be small, no harm in passing them by
value.

Change-Id: I151c87304949d810c72c42f60e9d1a7151f61f83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020780
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66007}

This adds accounting for
- StringTable that is marked black directly without going through
  ProcessMarkingWorklist.
- DescriptorArray that is marked black directly inside VisitMap.
- FeedbackMetadata that erroneously was assigned kVisitDataObject
  visitor id, which works only for a fixed size data object.

Bug: chromium:973627
Change-Id: If7c8bca06316f60e975bf86beea09481df8aca8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023545Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66006}

No-Try: true
Bug: chromium:1045795
Change-Id: I8313194bd1b0706291bd6a041d370a0b43215e10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020956Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66005}

RequestSweep started an array buffer sweeping task even when there was
no work.

Bug: chromium:1045937
Change-Id: Ieb0835284f898dbc9b899d2b4118d9f7f6108a6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020961
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66004}

The flag naming was confusing, and inconsistent with other flags. To
disable bounds checks, you now have to say --no-wasm-bounds-checks
instead of the original --wasm-no-bounds-checks. Similarly, it is now
--no-wasm-stack-checks instead of --wasm-no-stack-checks.

R=clemensb@chromium.org

Bug: v8:10021
Change-Id: Ib57963866af794d4e47d68e520a42b4054ed2a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017475
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66003}

Change-Id: I64b2ae64dc668a937be0bf2950199b4f3d543f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020778
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66002}

This reverts commit 015f379a.

Reason for revert: Msan is unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/30702

Original change's description:
> [wasm] Cache streaming compilation result
> 
> Before compiling the code section, check whether the
> bytes received so far match a cached module. If they do, delay
> compilation until we receive the full bytes, since we are likely to find
> a cache entry for them.
> 
> R=​clemensb@chromium.org
> 
> Bug: v8:6847
> Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66000}

TBR=clemensb@chromium.org,thibaudm@chromium.org

Change-Id: Idfa5b3f354816eb600ae7aab7857063d5d0d27ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6847
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022949Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66001}

Before compiling the code section, check whether the
bytes received so far match a cached module. If they do, delay
compilation until we receive the full bytes, since we are likely to find
a cache entry for them.

R=clemensb@chromium.org

Bug: v8:6847
Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66000}

Since the {kFinishedRecompilation} event can happen either before or
after the {kFinishedTopTierCompilation} event, we should not check it's
order relative to the other events.

R=ahaas@chromium.org

Bug: v8:10086
Change-Id: I880700b514c7c2238a0eb7791875bf0b81c64e97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020779Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65999}

R=clemensb@chromium.org

Fix: chromium:1045737
Change-Id: I0e27b8ff6ab09078a2f63f955e6123e1003ed889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020768Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65998}

This TODO clarifies intentions of 49f60a3b.

Bug: v8:9533
Change-Id: Ide448ae863a8716dafdcdd7fb27801a51655650e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022145Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Cr-Commit-Position: refs/heads/master@{#65997}

Bug: v8:9533
Change-Id: Id51430bb2ad7a782cf30542d0d7117d271079423
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019164Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Cr-Commit-Position: refs/heads/master@{#65996}

Utils::ReportApiFailure() contains logic to handle the case where no
isolate has been entered but it called Isolate::Current(), which DCHECks
when there is no active isolate. Switch to Isolate::TryGetCurrent().

See https://github.com/denoland/rusty_v8/issues/253 for background.

Change-Id: I73c28c31102c0c4ab216a925d22ad54174c7911d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020943Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65995}

We often only need to store information about declared (i.e.
non-imported) functions in a wasm module. Thus we remove the number of
imported function from a function index. We do this in several places,
with different amount of checking.

This CL extracts this logic to a new {declared_function_index} helper
and uses it wherever we do this translation. This more or less
establishes the concept of "declared function index" and hopefully
prevents errors in the future.

R=jkummerow@chromium.org

Bug: chromium:1045767
Change-Id: I7e957401495a2a8cb5d2c51031f9c69fe46195d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020763
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65994}

Fix the string representation of functions exported from asm.js modules
in the presence of imported functions.

R=jkummerow@chromium.org

Bug: chromium:1045767, chromium:667678
Change-Id: I55714252036511598eeec7fe7b81985213f7e4f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022142Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65993}

Deserialization bypasses the heap allocators, bumping pointers into the
spaces directly, instead.  So the deserializer is tightly coupled to the
implementation of the existing collector.

Here I've added an interface to heap.h for this purpose.  This CL
leaves things as-is unless the TPH is enabled, in which case the new
interface is used.

Future work: use the heap.h interface in all cases.

Bug: v8:9533

Change-Id: I3b1cc81870b347fbfb509ddb4031bd3781710240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019482
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65992}

Add a test that does the same thing the devtools-frontend does when
evaluating console inputs.

1) Declare a const variable with throwOnSideEffect=true. This should
throw.
2) Declare the same const variable with throwOnSideEffect=false.
This should successfully declare the variable.

Previously it could be the case that even though we threw in 1), the
variable would fail to be initialized in 2) with a re-declaration
error.

Bug: chromium:1043151
Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65991}

Bug: chromium:1033865
Change-Id: I63999575d4962124a4d9a64c4e661900aec5fa6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019167Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65990}

This CL introduces the negb and negw instructions (8-bit and 16-bit
versions of neg) in the x64 assembler. These instructions are needed to
implement I32AtomicSub8U and similar WebAssembly instructions
efficiently.

The existing implementation was embedded in a generic macro, and it was
difficult to change it without introducing also the 8-bit and 16-bit
versions of many other instructions. This would have introduced a lot
of dead code. Instead this CL extracted the neg instructions from the
macro and implements them directly. This should be fine because the
assembler does not change much, and approachability of the code is
improved.

R=clemensb@chromium.org

Bug: v8:10108
Change-Id: I46099bbebd47f864311a67da3ba8ddc4fe4cd35d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019165
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65989}

This extends the API to pass breakpoint information to Liftoff. The
Liftoff compiler identifies the places where breakpoints should be set,
but does not emit breakpoints yet.
This allows us to see the performance overhead of just checking where to
emit breakpoints (which should be negligible).

R=thibaudm@chromium.org

Bug: v8:10147
Change-Id: I3fd40ab9009e9c317a26f70b4f06db512f96a763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019169Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65988}

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

Change-Id: Ib6592ad50ae3764479c1a766bbb19042ee83b99d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018882
Auto-Submit: Justin Ridgewell <jridgewell@google.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65987}

When printing the source string, a backslash-newline sequence ('\\\n',
'\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
'\u2028', '\u2029', respectively. Prior to this CL it was formatted as
a backslash followed by the literal newline character.

Bug: v8:8615
Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65986}

Fixes edge cases for parsing / serializing codepoint 0xffff in JSON
with UTF16.

New Rev: 0213a8545f6362cd1cd5091cedf29747736552e8

Change-Id: I48b174cf1bd9263ace002996094f7143a1248766
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020502
Auto-Submit: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65985}