- 27 Nov, 2019 1 commit
-
-
Johannes Henkel authored
New revision: 7a44a37f66b58358dd8ab85ccde1998fafa95e53 Upstream review: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1899564 Previously, we used a wrapper library, v8-inspector-protocol-encoding.h to inject the string<->number conversion into the cbor parser. This meant that the unittests, in third_party/inspector_protocol/crdtp/json_test.cc inadvertently did not run with the same string<->number conversion code. Thus, we missed that the production implementation would return INF for out of range double literals, as opposed to rejecting the incoming JSON. When switching the library to the build dependency on json_platform_v8.cc as it's in this change, the test immediately failed which made it trivial to fix the implementation. Old implementation: https://chromium-review.googlesource.com/c/v8/v8/+/1913424/6/src/inspector/v8-inspector-protocol-encoding.cc New implementation (checks std::isfinite): https://chromium-review.googlesource.com/c/v8/v8/+/1913424/6/third_party/inspector_protocol/crdtp/json_platform_v8.cc Change-Id: Ia48fe1f4e359eea47d0ede9ceadea1fd635292e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1913424Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65219}
-
- 12 Nov, 2019 1 commit
-
-
Johannes Henkel authored
This decomposes the crdtp library into multiple files. Since it wasn't previously rolled it's a bit more than just that. Upstream review: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1907115 New Revision: d020a9e614d4a5116a7c71f288c0340e282e1a6e Change-Id: I5c588469654bec3e933804ac706fa967c6fe57bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1907973 Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64902}
-
- 28 Jun, 2019 1 commit
-
-
Johannes Henkel authored
New Revision: 8b7ea912e516a6daa61487c700687a9426e3a396 Update v8 files / build config accordingly. - There's now a new library in third_party/inspector_protocol, bindings/bindings.h, which is configured much like encoding/encoding.h. It doesn't have much stuff in it yet, but will soon get more code that would otherwise need to go into jinja templates. It also comes with a new test, only a smoke test thus far. Change-Id: I9c00a54a840c214b4bb744a3b272e5ce221954fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678273Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62442}
-
- 18 Dec, 2018 1 commit
-
-
Toon Verwaest authored
Since it's explicit what we're tracking, we can immediately throw errors in certain cases, and ignore irrelevant errors. We don't need to use the classifier itself to track "let let", since we know whether we're parsing a "let". Errors that were previously (almost) always accumulated are now immediately pushed to the scopes that care (parameter initialization errors). This CL drops avoiding allocation of classified errors, at least for now, but that doesn't affect performance anymore since we don't aggressively blacklist anymore. Classified errors are even less likely with the more precise approach. ParseAssignmentExpression doesn't introduce its own scope immediately, but reuses the outer scope. Rather than using full ExpressionClassifiers + Accumulate to separate expressions/patterns from each other while keeping track of the overall error state, this now uses an explicit AccumulationScope. When we parse (async) arrow functions we introduce new scopes that track that they may be (async) arrow functions. We track StrictModeFormal parameters in 2 different ways if it isn't immediately certain that it is a strict-mode formal error: Either directly on the (Pre)ParserFormalParameters, or on the NextArrowFunctionInfo in the case we're not yet certain that we'll have an arrow function. In the latter case we don't have a FormalParameter object yet, and we'll copy it over once we know we're parsing an arrow function. The latter works because it's not allowed to change strictness of a function with non-simple parameters. Design doc: https://docs.google.com/document/d/1FAvEp9EUK-G8kHfDIEo_385Hs2SUBCYbJ5H-NnLvq8M/ Change-Id: If4ecd717c9780095c7ddc859c8945b3d7d268a9d Reviewed-on: https://chromium-review.googlesource.com/c/1367809 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#58307}
-
- 17 Oct, 2018 1 commit
-
-
Toon Verwaest authored
This also fixes the tokens that are identified as called identifiers. Change-Id: I4a2179b98214f9018c8c07c0ab27f878cdae13cf Bug: v8:6513 Reviewed-on: https://chromium-review.googlesource.com/c/1286338Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56719}
-
- 08 Mar, 2018 1 commit
-
-
Teddy Katz authored
This updates the scanner to use the correct error message when it encounters an octal escape sequence in a template literal. Previously, the error message referred to strict mode, even when the template literal was not in strict mode code. Bug: v8:7502 Change-Id: I37bb1338cf796c471108bc10f35f824cdf3ce0b7 Reviewed-on: https://chromium-review.googlesource.com/945411Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#51823}
-
- 10 Jan, 2018 1 commit
-
-
Marja Hölttä authored
BUG=chromium:797581 Change-Id: I08f880a907f122480a014763975ecc07e2c49f7d Reviewed-on: https://chromium-review.googlesource.com/856937Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#50471}
-
- 09 Jan, 2018 1 commit
-
-
Choongwoo Han authored
The checked node and used node were mismatched. It checked if "var_unique" is a string, but it used "key" which may not be a string. Bug: v8:4911, v8:7161, chromium:800077 Change-Id: Ia2aee8b77ac33500430365a4800bf9cca40a28fc Reviewed-on: https://chromium-review.googlesource.com/855138Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#50435}
-