- Removes Utf8Iterator
- Replaces Utf8Decoder with something based on ValueOfIncremental +
NonAsciiStart and moves it into v8/internal.
- Internalizes utf8 strings by first converting them to one or two byte
- Removes IsUtf8EqualsTo and replaces current uses with IsOneByteEqualsTo
Tbr: jgruber@chromium.org
Change-Id: I16e08d910a745e78d6fd465718fc69ad731fd217
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585840
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61049}
The function {memory_copy_wrapper} is called directly from WebAssembly.
Before calling {memory_copy_wrapper} we do not reset the
tread-in-wasm flag. On asan builds on Windows this causes the problem
observed in the crash report.
My theory is the following: asan on Windows uses exceptions to allocate
shadow memory lazily. When {memory_copy_wrapper} accesses memory, asan
causes an exception to allocate shadow memory. This exception is first
caught by the WebAssembly trap handler, which resets the
thread-in-wasm flag but then does not handle the exception because it
cannot find a proper landing pad. Asan then handles the exception and
continues execution. However. the thread-in-wasm flag is not set
anymore. A later check of the thread-in-wasm flag then fails.
This CL disables asan for {memory_copy_wrapper} and thereby fixes the
problem. As indicated above, another solution would be to reset and set
the thread-in-wasm flag before and after the call to the C function,
respectively. However, we do not do that for other uses of direct calls
to C.
R=binji@chromium.org
Bug: chromium:952342
Change-Id: I2adb2eccf2ac25be58392d21f8f43a04414c7811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584326
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61040}
This reverts commit da7322c05f.
Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
>
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
>
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
>
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
> Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
>
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
> (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
> We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
> but in CSA.
>
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
>
> R=jarin@chromium.org
> TBR=mvstanton@chromium.org
>
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}
TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
The generation of unwind info to enable stack walking on Windows/x64
(https://chromium-review.googlesource.com/c/v8/v8/+/1469329) was implemented
behind a temporary flag, in order to coordinate these changes with the
corresponding changes in Chromium.
The required changes to Chromium
(https://chromium-review.googlesource.com/c/chromium/src/+/1474703) have also
been merged, so we can now remove the flag and enable the generation of stack
unwinding info by default on Windows/x64.
Bug: v8:3598
Change-Id: I88814aaeabecc007f5262227aa0681a1d16156d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1573138
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#61020}
With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.
Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).
Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.
Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
(for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
but in CSA.
Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).
R=jarin@chromium.orgTBR=mvstanton@chromium.org
Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
Adds a new flag to CpuProfiler to control whether or not "debug" names
(potentially inferred from scope) are used for captured frames
associated with a SharedFunctionInfo instance.
Bug: v8:9135
Change-Id: Ia1db20e389f3d0beb60eb47798820fb11d501c88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583042
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61015}
This CL fixes a crash that happens on a goto definition lookup for a
file with no data attached to it.
Drive-by: Collect language server data even on compilation failures.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: Ia6323204391da3e64058e1fe47f87162186c15cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61012}
This is a reland of 3d846115d6
Reland changes mjsunit.status to skip the regression test on
all bots except ASAN.
Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
>
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
>
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
>
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
>
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
>
> R=neis@chromium.org, petermarshall@chromium.org
>
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}
Bug: v8:9161
Change-Id: Idffc3fbb5f28f4966c8f1ac6770d5b5d6003a7e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583726
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61011}
Verify that baseline and top tier compilation are finished when
expected. Test cases will use the newly exposed functions
{baseline_compilation_finished} and {top_tier_compilation_finished} for
this.
Bug: v8:9003
Change-Id: I023af3390ed5e087a3b40efe7c340d7e93071a51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581941
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Frederik Gossen <frgossen@google.com>
Cr-Commit-Position: refs/heads/master@{#61010}
This reverts commit 3d846115d6.
Reason for revert: The test hangs flakily on windows:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20612https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/33147https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19945
Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
>
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
>
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
>
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
>
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
>
> R=neis@chromium.org, petermarshall@chromium.org
>
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}
TBR=neis@chromium.org,petermarshall@chromium.org,szuend@chromium.org
Change-Id: I046da3e4228bb1a8a3aa89d9c9d8de11875a9273
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9161
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583725
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61007}
It shipped in Chrome 73.
Bug: v8:6890
Change-Id: Idd8c98cf05a0d6e8fa58c5b0a34d079631f68b1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1582879
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61005}
TypedArray#sort has a fast-path when the user does not provide a
comparison function. This fast-path utilizes std::sort which operates
directly on the raw data. Per spec, std::sort requires the "less than"
operation to be anti-symmetric and transitive.
When sorting SharedArrayBuffers (SAB) that are concurrently modified during
sorting, the "less than" operator stops being consistent as the
underlying data is constantly modified. This breaks some invariants
in std::sort resulting in infinite loops or straight out segfaults.
This CL fixes this by copying the data before sorting SABs and
writing the sorted result back.
Note: The added regression test is tailored for ASAN bots as a
normal build would need too many iterations to consistently crash.
R=neis@chromium.org, petermarshall@chromium.org
Bug: v8:9161
Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61004}
This CL refactors and extends the infrastructure around sending
diagnostic notifications. This enables publishing lint errors as
warnings after a compilation run.
R=sigurds@chromium.org, tebbi@chromium.org
Bug: v8:8880
Change-Id: Ia64d2d490c1449021c92f5dc45eb7f8dab21e60a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1582405
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61003}
Make sure to adapt the formal parameters for the Promise.allSettled
method.
Bug: v8:7834
Change-Id: I255fc695f5ac0d62ed18f5aad78665feb38c241a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1580239
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60996}
This CL changes lint errors to not be printed directly to stderr.
Instead, they are collected in a list that gets surfaced via
the TorqueCompilerResult. This is done so they can be presented
to language server clients.
This change also removes the "abort_on_lint_errors" option.
API users can now decide for themselves what to do, depending on
the presence of lint errors in the returned list.
R=sigurds@chromium.org, tebbi@chromium.org
Bug: v8:8880
Change-Id: I44601010491aafcf4c8609fd8c115219317506a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581608
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60983}
This fixes the bounds check for the 'in' operator to handle the negative
index case properly (by using the same machinery as the potentially
out-of-bounds loads/stores use).
Bug: chromium:952586
Change-Id: I2225acae8be7dcedbcde745e8ef202e789085041
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581179
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60978}
This extends the existing test coverage of interactions between the
exception handling and the reference type proposal. Now "any-func" and
"except-ref" can both be encoded as an exception value. Missing switch
cases have been added.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref[-interpreter]
BUG=v8:8091,v8:7581
Change-Id: Ie2e9819fe66b4daab623390f27bb19007131f619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581600
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60977}
On Arm/64 the last return address is stored in a link register instead of
being pushed to the top-of-stack like on x64/ia32. Extend the support in the
tick sampler to check for samples in a frameless bytecode handler with support
for checking the link register if it exists instead of top-of-stack. In addition,
make the x64/ia32 check more robust by ensuring we only apply the change if the
pc is a bytecode handler and the top frame isn't a bytecode handler (stub) frame.
BUG=v8:9162
Change-Id: I89d2e80ea8a0b84ff6a265d0e0e73f9fdd1daca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578464
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60976}
Use the existing {ArrayVector} method for this, which reads nicer. In
some places, I replaced a stack-allocated array by {EmbeddedVector} to
avoid the {ArrayVector} call.
R=mstarzinger@chromium.org
Bug: v8:8834
Change-Id: I5560c07f2775338fefd11acf67a540e003428e74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578899
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60975}
This is one step towards removing the {StrLength} helper and using
{size_t} consistently instead.
R=mstarzinger@chromium.org
Bug: v8:8834
Change-Id: Ibcdfd579531a259d490c39a8e8c96d469a5a4aac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578901
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60974}
This reverts commit fa6ec3cb08.
Reason for revert: v8:9169, v8:9170
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/31457https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64/31417https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19919
Original change's description:
> [cpu-profiler] Split out debug mode for CPU profiler naming
>
> Adds a new flag to CpuProfiler to control whether or not "debug" names
> (potentially inferred from scope) are used for captured frames
> associated with a SharedFunctionInfo instance.
>
> Bug: v8:9135
> Change-Id: I104f3246431dc6336de4e4688c0d98c86e0bb776
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566169
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60972}
TBR=ulan@chromium.org,alph@chromium.org,yangguo@chromium.org,petermarshall@chromium.org,acomminos@fb.com
Change-Id: I573194b5affd31fd0748b9ef3c45052e8ab420f5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9135
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581639
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60973}
Adds a new flag to CpuProfiler to control whether or not "debug" names
(potentially inferred from scope) are used for captured frames
associated with a SharedFunctionInfo instance.
Bug: v8:9135
Change-Id: I104f3246431dc6336de4e4688c0d98c86e0bb776
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566169
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60972}
In the PerformPromise{All, Race, AllSettled} operations, the resolve
property of the constructor is looked up only once.
In the implementation, for the fast path, where the constructor's
resolve property is untainted, the resolve function is set to undefined.
Since undefined can't be a valid value for the resolve function,
we can switch on it (in CallResolve) to directly call the PromiseResolve
builtin. If the resolve property is tainted, we do an observable property
lookup, save this value, and call this property later (in CallResolve).
I ran this CL against the test262 tests locally and they all pass:
https://github.com/tc39/test262/pull/2131
Spec:
- https://github.com/tc39/ecma262/pull/1506
- https://github.com/tc39/proposal-promise-allSettled/pull/40
Bug: v8:9152
Change-Id: Icb36a90b5a244a67a729611c7b3315d2c29de6e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574705
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60957}
The WebAssembly JavaScript Interface specifies[1] that exported
functions are not constructors, hence do not have the "prototype"
property. This is not true for asm.js exported functions which are
expected to look like normal functions (or constructors).
[1] https://webassembly.github.io/spec/js-api/index.html#exported-function-exotic-objectsR=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-935800
BUG=chromium:935800
Change-Id: Idecacfb7f5d4668540589af95fd59872334c21a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60943}
This CL implements the first set of diagnostic notifications.
When Torque compilation fails, the language server translates the
Torque error into a diagnostics notification and pushes it to the
client.
Note that per specification, the server is responsible to manage the
state of all published diagnostics. This means that the server is
also responsible for clearing out previous notifications if they
become stale.
Bug: v8:8880
Change-Id: Ief46dc1d94d1e5b7fa3e0048df494bfc05974031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569434
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60942}
