- 13 Jan, 2021 1 commit
-
-
Kim-Anh Tran authored
This skips sending the data urls along with Runtime.CallFrame, and Runtime.ExceptionDetails. Also-by: bmeurer@chromium.org Bug: chromium:1132260 Change-Id: I45136bc0d3217caf8fbd93946b021f56f64f04b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621077 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72063}
-
- 11 Jan, 2021 1 commit
-
-
Eric Leese authored
New internal properties expose the byte length of an ArrayBuffer as well as the pointer to the backing store, which will serve as a unique ID to show when SharedArrayBuffers in different workers are the same buffer. Bug: chromium:1163800 Change-Id: I49930765cb38f75ba5c6cee5a0a6827f4fec42d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618242 Commit-Queue: Eric Leese <leese@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72000}
-
- 29 Dec, 2020 1 commit
-
-
Benedikt Meurer authored
For JSArrayBuffer instances (which map to both v8::ArrayBuffer and v8::SharedArrayBuffer), we add a couple of synthetic views to its ValueMirror to make it easy for developers to peak into the contents of the JSArrayBuffer. These were previously real properties, but that's just wrong (both intuitively and semantically), and they should instead be internal properties. Drive-by-fix: The [[IsDetached]] internal property should only be shown on actually detached JSArrayBuffer's to reduce visual clutter. And for detached JSArrayBuffers creating views on them throws TypeErrors per specification, so we shouldn't attempt to display views on them. Bug: v8:9308, chromium:1162229 Change-Id: Ia006de7873ca4b27aae7d00d46e1b69d2e326449 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606047 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71892}
-
- 23 Dec, 2020 1 commit
-
-
Andrey Kosyakov authored
This adds ExecutionContextDescription.uniqueId for a system-unique way to identify an execution context and supports it in Runtime.evaluate. This allows a client to avoid accidentally executing an expression in a context different from that originally intended if a navigation occurs while Runtime.evaluate is in flight. Design doc: https://docs.google.com/document/d/1vGVWvKP9FTTX6kimcUJR_PAfVgDeIzXXITFpl0SyghQ Bug: v8:11268, chromium:1101897 Change-Id: I4c6bec562ffc85312559316f639d641780144039 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594538 Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#71869}
-
- 10 Dec, 2020 1 commit
-
-
Peter Marshall authored
Function prototypes can be lazily allocated. This means they go into the temporary objects set that debug-eval uses to figure out if a write will be side-effect free. We were incorrectly classifying writes to function prototypes as side-effect free because the prototype happened to be lazily allocated when we first accessed it during debug-eval, but was actually reachable from the function (not allocated temporarily). To do this we introduced a way to temporarily turn off the temporary object tracking, and we use it when lazily allocating function prototypes. This could mean that we incorrectly report side-effects when writing to function prototypes for functions which were themselves created during debug-eval side-effect free mode. However, it's unclear if this is a problem, because function declarations set global variables which would already throw due to side-effects. Bug: chromium:1154193 Change-Id: I444a673662095f6deabaafdce3cdf3d86b71446d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581968Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#71692}
-
- 27 Oct, 2020 1 commit
-
-
Simon Zünd authored
The crash scenario is as follows: 1) Add a getter for 'then' to the Object prototype that is considered side-effecting. 2) Evaluate a simple string using 'REPL' mode with side-effect checks enabled. Note: REPL mode is not strictly necessary, but it causes a 'then' lookup as the evaluation result is not a promise. 3) Calling the 'then' getter causes a termination exception, due to the side-effect check. JSPromise::Resolve then tries to put the termination exception as the reject reason, which causes a CHECK failure. The solution is to check for termination in the "abrupt completion" case when 'then' was retrieved. Bug: chromium:1140845 Change-Id: I72b644cd49355cea40f599fcbe80264e99ed7bd6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501283Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#70785}
-
- 18 Oct, 2020 1 commit
-
-
Dmitry Gozman authored
This changes remoteObjectId format from "{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>". Prepending isolateId fixes the problem that remote object ids clash between processes. This is especially troubling during cross-process navigation in Chromium, see bug. We also stop producing and parsing unnecessary json for object ids. Drive-by: fixed some tests dumping object ids. Most tests avoid dumping unstable values like ids, but there were few that still did. BUG=chromium:1137143 Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731 Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#70592}
-
- 01 Oct, 2020 2 commits
-
-
Andrey Kosyakov authored
This adds support for injecting binding into contexts other than main based on the context name (AKA isolated world name in Blink terms). This would simplify a common use case for addBinding in Puppeteer and other automation tools that use addBinding to expose a back-channel for extension code running in an isolated world by making bindings available to such code at an early stage and in a race-free manner (currently, we can only inject a binding into specific context after the creation of the context has been reported to the client, which typically introduces a race with other evals the client may be running in the context). Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#70266}
-
Andrey Kosyakov authored
... when addBinding is called with contextId. Previously, due to a subtle type, we exposed bidings added with executionContextId to all contexts created after the binding was added. Also, do not persist context-specific bindings to agent state, as context ids don't make sense across the process. This also adds a test instrastructure to create additional context in given context group. Change-Id: I1b3e96cb65b756424bc7872d200bbbf41e4c30b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440982Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#70261}
-
- 28 Sep, 2020 1 commit
-
-
Simon Zünd authored
The compilation cache doesn't know about REPL mode. This means that non-REPL mode compiled scripts are successfully found for their REPL mode equivalent and vice versa. This CL disables the compilation cache for REPL mode scripts. Performance is not really a concern as DevTools console inputs are usually very small. R=leszeks@chromium.org Bug: chromium:1108021 Change-Id: If396c7aa004188730762e4f6bd01dae2fc141181 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434333 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70160}
-
- 18 Aug, 2020 1 commit
-
-
Ulan Degenbaev authored
Instead of forcing GC right away, the function now post a task and performance GC from the task with an empty stack to avoid false positive pointers in conservative stack scanning. Bug: chromium:1098187 Change-Id: I88864845a1e395056c5d5f6e867ad774b87dbb6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307217 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69444}
-
- 27 Jul, 2020 1 commit
-
-
Sigurd Schneider authored
Currently, only a scriptURL is reported, which can be over-written by sourceURL comments of the script. This means a script can basically claim to come from anywhere. This means that DevTools doesn't know the resource name the embedder provided if there is a sourceURL comment. This CL adds a `embedderName` field to the scriptParsed and scriptFailedToParse events that reports the name the embedder associated with the script. Bug: chromium:974543 Change-Id: I9863f878f57638174847890d9a3818952b1efc27 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317310 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#69078}
-
- 24 Jul, 2020 1 commit
-
-
Benedikt Meurer authored
This adds an internal property [[IsDetached]] to the inspector preview of ArrayBuffer instances, which indicates whether the ArrayBuffer was detached (i.e. transfered via `postMessage`). Previously it was rather impossible to tell whether an ArrayBuffer was detached, you had to know that V8 violates the ECMAScript specification and simply sets the byteLength accessor to 0 upon detaching an ArrayBuffer (but even then it was still impossible to tell whether that ArrayBuffer wasn't simply an empty one from the get go). Before: https://imgur.com/UcOF83c After: https://imgur.com/WjmTehZ Fixed: chromium:1109102 Change-Id: I8fb6e2be2fbfe5c62b05dc9d2a0f18378eb4de6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316075 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#69034}
-
- 02 Jul, 2020 1 commit
-
-
Andrey Kosyakov authored
Note that changes in test expectation come from a more verbose error diagnostics for expected errors around input parameter validation. Original change: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2270757 Bug: chromium:1099809 Change-Id: I4fc2efc9c89d0af645dad937d719fa36e1d33489 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2277142Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#68657}
-
- 15 May, 2020 1 commit
-
-
Marja Hölttä authored
They're exposed via DevTools. - [[PromiseStatus]] → [[PromiseState]] - [[PromiseValue]] → [[PromiseResult]] - [[GeneratorStatus]] → [[GeneratorState]] Related CLs: - Chromium CL temporarily disabling affected tests: https://chromium-review.googlesource.com/c/chromium/src/+/2203201 - Chromium CL re-enabling affected tests: https://chromium-review.googlesource.com/c/chromium/src/+/2202900 Bug: v8:10506, v8:5416 Change-Id: Id12fb0f2ba2b453139a5d74afff9021108c15f08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202984Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#67825}
-
- 14 May, 2020 1 commit
-
-
Varun Varada authored
There should be a space between the quantity and the unit symbol as per the SI, so this commit fixes this issue. Change-Id: I3356942391d96906f3e3840c7bb802e10f29eb4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190230 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67789}
-
- 07 May, 2020 1 commit
-
-
Yang Guo authored
R=szuend@chromium.org Fixed: chromium:1078205 Change-Id: I16f8e19a249692fd16fd53a9a56a8f4cfed8b5c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185134 Auto-Submit: Yang Guo <yangguo@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#67634}
-
- 28 Apr, 2020 1 commit
-
-
Yang Guo authored
R=szuend@chromium.org Fixed: chromium:1075763 Change-Id: I7f67cfb9c643d8f30bec808ccb2a9e1326ad1921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170030Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67450}
-
- 17 Apr, 2020 1 commit
-
-
Yang Guo authored
Fixed: chromium:986051 Change-Id: I01ef94fe43ac5c8734890706a6dccd01e008bfec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153215Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67204}
-
- 16 Apr, 2020 1 commit
-
-
Ulan Degenbaev authored
On-heap TypedArrays have empty ArrayBuffers that are not supposed to be accessed directly. Such ArrayBuffers materialize properly when accessed via their TypedArrays. The queryObjects() sidesteps the bottleneck and finds empty ArrayBuffers by iterating the heap. When preview TypedArrays are constructed for the found ArrayBuffers, they get nullptr data pointers. This CL converts all on-heap TypedArrays into off-heap TypedArrays in queryObjects to make sure that all found ArrayBuffers are valid. Bug: chromium:992442 Change-Id: Ie77d1e75aa2007b4a976c72206b9a4e215c9ef53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150601 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#67174}
-
- 09 Apr, 2020 1 commit
-
-
Mathias Bynens authored
Per the spec [1], a resolved promise may be “pending, fulfilled, or rejected”, but previously V8 incorrectly used the term “resolved” instead of “fulfilled”. This change is user-observable through the `d8` REPL and the DevTools Console. Corresponding DevTools CL: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2141673 Corresponding Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/2144095 [1]: https://tc39.es/ecma262/#sec-properties-of-promise-instances Bug: v8:6751, v8:5416 Change-Id: I6c5302c280d01cf681c6358add3d2e88fbffa36f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144011 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#67086}
-
- 17 Mar, 2020 1 commit
-
-
Philip Pfaffe authored
Add a scriptLanguage enum to the new scripts events. This overhauls crrev.com/c/2011083 that was related. Report the code section offset as well as the script language on the Debugger.scriptParsed and Debugger.scriptFailedToParse events. Bug: chromium:1057569 Change-Id: I40b43f28f0b3e094720db4fc1f07db1a0c293ee0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083025Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#66749}
-
- 18 Feb, 2020 1 commit
-
-
Simon Zünd authored
REPL 'let' declared variables use VariableLocation::REPL_GLOBAL which was not handled by a switch in the bytecode generator. The default case ran into an UNREACHABLE. This CL fixes this by properly handling VariableLocation::REPL_GLOBAL for delete. Drive-by: Replaced the default case with an explicit case for VariableLocation::MODULE. Bug: chromium:1052721 Change-Id: I1330ff2f2c6f042a596a8298599a5d58769894f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060488 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66301}
-
- 28 Jan, 2020 1 commit
-
-
Simon Zünd authored
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}
-
- 27 Jan, 2020 1 commit
-
-
Peter Marshall authored
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}
-
- 22 Jan, 2020 1 commit
-
-
Peter Marshall authored
Add a test that const declarations are recognized as having side- effects in REPL mode. Bug: chromium:1043151 Change-Id: I6f8038ab4a5ee446d23904ed46637223157db5c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013114Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#65916}
-
- 21 Jan, 2020 1 commit
-
-
Simon Zünd authored
This fixes the DevTools console preview when using REPL mode. AsyncFunction* intriniscs are side-effect free and marking them as such is correct. Bug: chromium:1043151 Change-Id: Ie0c36507b98b0c12f3d627c34102c04c27358ff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010106Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65876}
-
- 18 Dec, 2019 1 commit
-
-
Simon Zünd authored
When V8 throws an uncaught exception, we store a JSMessageObject with a stack trace and source positions on the isolate itself. The JSMessageObject can be retrieved by a TryCatch scope and is used by the inspector to provide additional information to the DevTools frontend (besides the exception). Introducing top-level await for REPL mode causes all thrown exceptions to be turned into a rejected promise. The implicit catch block that does this conversion clears the JSMessageObject from the isolate as to not leak memory. This CL preserves the JSMessageObject when the debugger is active and stores the JSMessageObject on the rejected promise itself. The inspector is changed to retrieve the JSMessageObject in the existing catch handler and pass the information along to the frontend. Drive-by: This CL removes a inspector test that made assumptions when a promise is cleaned up by the GC. These assumptions no longer hold since we hold on to the promise longer. Bug: chromium:1021921 Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65497}
-
- 28 Nov, 2019 1 commit
-
-
Peter Marshall authored
Reverting https://chromium-review.googlesource.com/c/v8/v8/+/1741660 This fixed one bug but caused a lot of others and on balance I think reverting it is the lesser evil. This also fixed generator-relocation.js because (function*(){}).constructor is the function constructor and we try to set a breakpoint on line 3. Bug: chromium:109362, chromium:1028689 Fixes: v8:9721 Change-Id: I1bfe6ec57ce77ea7292df91266311f5c0194947e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940259 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#65232}
-
- 06 Nov, 2019 1 commit
-
-
Simon Zünd authored
There already exists a optional boolean flag 'replMode' for the 'Runtime.evaluate' command. This CL ferries the flag from the inspector to DebugEvaluate::Global. The existing DebugEvaluate::GlobalREPL is removed in favor of a the REPLMOde enum to reduce code duplication. Bug: chromium:1018158 Change-Id: Iafb43a3015b6876a02ac0db6cdfcac2cfa388862 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881149 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64801}
-
- 27 Sep, 2019 1 commit
-
-
Benedikt Meurer authored
This new optional parameter controls whether "Runtime.evaluate" ignores break points and previous "Debugger.pause" calls while evaluating the expression. This will be used for live expressions, which should never interfere with debugging. Bug: chromium:1001216 Change-Id: Ie37f6616a4a1cae40399b79255ab92fb254d91b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826664 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64018}
-
- 02 Sep, 2019 1 commit
-
-
Yang Guo authored
R=sigurds@chromium.org Bug: chromium:956475 Change-Id: Ie4ccd84e1c239d771fd9238599c687782ddb1356 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776097Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63505}
-
- 23 Aug, 2019 1 commit
-
-
Yang Guo authored
Running microtasks with exceptions scheduled violates varios invariants within the microtasks code. Bug: v8:9652 Change-Id: I78c868feed5b742e225cad19e55216f0ef250af4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1767261Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Cr-Commit-Position: refs/heads/master@{#63380}
-
- 09 Aug, 2019 1 commit
-
-
Yury Semikhatsky authored
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'. R=dgozman@chromium.org, lushnikov@chromium.org Bug: v8:9509 Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Yury Semikhatsky <yurys@chromium.org> Cr-Commit-Position: refs/heads/master@{#63134}
-
- 08 Aug, 2019 1 commit
-
-
Peter Marshall authored
The spec says we have to insert some wrapper code with extra line breaks in it, but this confuses users when they see stack traces as the line numbers come from the code with the wrapper, instead of the original. This CL sets line_offset on the script to indicate that line numbers should be offset by the 2 extra line breaks when reading them out e.g. for the purpose of stack traces. Bug: chromium:109362 Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63127}
-
- 07 Aug, 2019 1 commit
-
-
Simon Zünd authored
This CL changes {descriptionForError} to not immediately return when a {stack} is not found, but instead try to lookup and append the {message} as well. The existing logic to build a description in a specific way when the class of the exception does not match, is retained for backwards compatibility. Bug: chromium:954017 Change-Id: I9fa1d2807e2877bd988f82b4b57cf329bcd9f61b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738862 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63111}
-
- 18 Jun, 2019 1 commit
-
-
Yang Guo authored
R=petermarshall@chromium.org Bug: chromium:952455 Change-Id: Ib08a20e1d1fac7ef943f15ff524ee4e7c1c15507 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662290 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62261}
-
- 12 Jun, 2019 2 commits
-
-
Andrey Lushnikov authored
This was originally reported at https://github.com/GoogleChrome/puppeteer/issues/4545 R=ulan, alph Change-Id: I5134506e56cd40e49b358cd47590913b81013b6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649473 Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62129}
-
Aleksei Koziatinskii authored
JSModuleNamespace does not have well defined CreationContext: current implementation of JSReceiver::GetCreationContext crashes on CHECK. R=lushnikov@chromium.org,yangguo@chromium.org Bug: none Change-Id: Ie2c0bfa39117d42d81f9709c21376c177b18e5ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652559Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62128}
-
- 11 Jun, 2019 1 commit
-
-
Oliver Dunk authored
Quotes have been added around the token to make the message clearer. Bug: chromium:943636 Change-Id: Ic38f3e6d307157af2c0146e69fb611a2cfb46564 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593307 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62074}
-