- 18 Jun, 2020 1 commit
-
-
Dan Elphick authored
When preparsing and detecting a sloppy block function redefinition then don't mark the variable as assigned to make it consistent with the eager parser. Bug: chromium:1053364 Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68415}
-
- 22 Apr, 2020 1 commit
-
-
Leszek Swirski authored
This is a reland of e1b93a4f which was a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Give up on using C++ bitfields, go back to having base::BitField and getters/setters. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67309}
-
- 21 Apr, 2020 4 commits
-
-
Leszek Swirski authored
This reverts commit e1b93a4f. Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274 Original change's description: > Reland^4 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 313d4844 > which was a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Manually zero out flags with memset, since GCC appears not to initialize > the bitfield values to zero even with a default constructor. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67271} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67275}
-
Leszek Swirski authored
This is a reland of 313d4844 which was a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Manually zero out flags with memset, since GCC appears not to initialize the bitfield values to zero even with a default constructor. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org Bug: v8:10314 Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67271}
-
Sathya Gunasekaran authored
This reverts commit 313d4844. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354 Original change's description: > Reland^3 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of 0a59e0cb > which was a reland of 146f5375 > which was a reland of d91679bf > > Initializes the BackgroundCompileTasks's language_mode in the > constructor (previously only initialized after successful parse) in case > the parse failed. We still need to reset it after parse in case the > language mode changed (because we encountered "use strict"). > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org > > Bug: v8:10314 > Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67265} TBR=leszeks@chromium.org Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67266}
-
Leszek Swirski authored
This is a reland of 0a59e0cb which was a reland of 146f5375 which was a reland of d91679bf Initializes the BackgroundCompileTasks's language_mode in the constructor (previously only initialized after successful parse) in case the parse failed. We still need to reset it after parse in case the language mode changed (because we encountered "use strict"). Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org Bug: v8:10314 Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67265}
-
- 20 Apr, 2020 4 commits
-
-
Francis McCabe authored
This reverts commit 0a59e0cb. Reason for revert: Still causing UBSAN issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729 Original change's description: > Reland^2 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > which was a reland of d91679bf > > Fixes missing initialization of ParserBase::allow_eval_cache_ > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org > > Bug: v8:10314 > Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67245} TBR=rmcilroy@chromium.org,leszeks@chromium.org Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67250}
-
Leszek Swirski authored
This is a reland of d91679bf which was a reland of d91679bf Fixes missing initialization of ParserBase::allow_eval_cache_ Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67245}
-
Leszek Swirski authored
This reverts commit 146f5375. Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?) Original change's description: > Reland "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > > This reland adds initializers for the output flags. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > Bug: v8:10314 > Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67241} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67242}
-
Leszek Swirski authored
This is a reland of d91679bf This reland adds initializers for the output flags. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} Bug: v8:10314 Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67241}
-
- 02 Apr, 2020 1 commit
-
-
Toon Verwaest authored
Otherwise we'll invalidly propagate information from default function parameters outwards to outer arrow scopes. Bug: chromium:1060023 Change-Id: Id43ecb5e1d354d5250a80c2a4f7e3129759041d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134006 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66964}
-
- 19 Mar, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit d91679bf. Reason for revert: Seems to cause UBSan errors Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66783}
-
Leszek Swirski authored
UnoptimizedCompileFlags defines the input flags shared between parse and compile (currently parse-only). It is set initially with some values, and is immutable after being passed to ParseInfo (ParseInfo still has getters for the fields, but no setters). Since a few of the existing flags were output flags, ParseInfo now has a new output_flags field, which will eventually migrate to a ParseOutputs structure. Bug: v8:10314 Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66782}
-
- 30 Jan, 2020 1 commit
-
-
Jan Krems authored
When the file begins with a hashbang, the scanner is in a failed state when SkipHashbang() is called. This is usually not an issue but when the parser encounters an ILLEGAL token, it will reset the SyntaxError location because of it. Bug: v8:10110 Change-Id: I1c7344bf5ad20079cff80130c991f3bff4d7e9a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995312Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66038}
-
- 06 Dec, 2019 1 commit
-
-
Simon Zünd authored
This is a reland of 5bddc0e1 The original CL was speculatively reverted as it was suspected to cause failures on the non-determinism bot. This was ultimately confirmed to not be the case, so this CL is safe to reland as-is. Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR: yangguo@chromium.org,verwaest@chromium.org Bug: chromium:1021921 Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65360}
-
- 04 Dec, 2019 1 commit
-
-
Maya Lekova authored
This reverts commit 5bddc0e1. Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863 Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1021921 Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65333}
-
- 02 Dec, 2019 1 commit
-
-
Simon Zünd authored
Design doc: bit.ly/v8-repl-mode This CL allows the usage of 'await' without wrapping code in an async function when using REPL mode in global evaluate. REPL mode evaluate is changed to *always* return a Promise. The resolve value of the promise is the completion value of the REPL script. The implementation is based on two existing mechanisms: - Similar to async functions, the content of a REPL script is enclosed in a synthetic 'try' block. Any thrown error is used to reject the Promise of the REPL script. - The content of the synthetic 'try' block is also re-written the same way a normal script is. This is, artificial assignments to a ".result" variable are inserted to simulate a completion value. The difference for REPL scripts is, that ".result" is used to resolve the Promise of the REPL script. - ".result" is not returned directly but wrapped in an object literal: "{ .repl_result: .result}". This is done to prevent resolved promises from being chained and resolved prematurely: > Promse.resolve(42); should evaluate to a promise, not 42. Bug: chromium:1021921 Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65273}
-
- 25 Nov, 2019 1 commit
-
-
Dan Elphick authored
Converts and uses of RuntimeCallTimerScopes that switch the counter based on the thread, to use kThreadSpecific and remove the counter selection. Also moves RuntimeCallTimerScope::CounterMode to RuntimeCallStats, since now CorrectCurrentCounterId also takes it as a parameter. Bug: v8:10006 Change-Id: I14a503e0b83bb69c071f9665956de094bb33c0ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928864Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65141}
-
- 29 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Sloppy eval extends the outer declaration scope's context. This is also true for sloppy eval inside of other sloppy evals -- the outer declaration scope's context is extended rather than the outer sloppy eval's declaration scope. However, we consider eval scopes to also be declaration scopes, for the purposes of strict eval and caching lookup variables. So, we need to make sure that we skip through sloppy eval scopes when marking a scope as calls_sloppy_eval. In fact, we implement this rather as never marking sloppy eval scopes as calls_sloppy_eval, under the assumption that the parent scope will already have been marked calls_sloppy_eval by the outer eval. As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to RecordEvalCall(), rename the variable to something more meaningful, and make Snapshotting to use a new calls_eval bit on Scope. Bug: chromium:996751 Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63455}
-
- 23 Aug, 2019 1 commit
-
-
Shu-yu Guo authored
- Rename FunctionLiteral::FunctionType to FunctionSyntaxKind. - Re-express IsWrappedBit, IsDeclarationBit, IsAnonymousExpressionBit, and IsNamedExpressionBit in SFI::flags as FunctionSyntaxKind. This frees up 1 bit in SFI::flags. - Re-express the analogous bits in ParseInfo as FunctionSyntaxKind. - Simplifies some logic in the back-and-forth passing of this info between SFI and ParseInfo. - Drive-by fix parsing class member initializations as kAccessorOrMethod. Bug: v8:9644 Change-Id: I6c165d5016d968f5057a32136385ddcdc4a46ef1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1767263Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#63388}
-
- 11 Jun, 2019 1 commit
-
-
Caitlin Potter authored
It was a good flag, but it's time to say goodbye. Let us take a moment to remember the good times we've had during its short time on earth. It shipped in Chrome 74. BUG=v8:8523 R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Auto-Submit: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#62099}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I9bcf2694b449f79cdbe03f5fde59cb21b8cad418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619758 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61676}
-
- 15 May, 2019 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org, clemensh@chromium.org, jkummerow@chromium.org, sigurds@chromium.org, ulan@chromium.org, verwaest@chromium.org Bug: v8:9247 Change-Id: I153a6bbfc55989fe7a86c052f95c5cb8ee61e841 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613244 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61557}
-
- 11 Apr, 2019 1 commit
-
-
Toon Verwaest authored
Previously we'd need to eagerly compile upon access to function.length for a lazy function. The preparser already computes function.length, however, so we can store that information in the already available preparse data. Change-Id: I19007c9db5839e8038291fb4433866303935f089 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564190 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60767}
-
- 26 Feb, 2019 1 commit
-
-
Toon Verwaest authored
GetSymbol previously always internalized the underlying string, even if the preparser does not need it. The most common case where this isn't needed is property name parsing. This seems to speed up preparsing quite a bit. For future reference: Property names in object literals still are needed due to various checks (e.g., get 'constructor', duplicate __proto__, ...); as well as cover grammar parsing (property names can turn into variable references). If we turn all strings that the preparser needs to identify back into contextual keywords we may be able to avoid the former. Change-Id: I549e4600053de3136ca08d4915cc04db36d66a89 Reviewed-on: https://chromium-review.googlesource.com/c/1488764Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59866}
-
- 15 Feb, 2019 1 commit
-
-
Jakob Kummerow authored
This takes heap-inl.h out of the "Giant Include Cluster". Naturally, that means adding a bunch of explicit includes in a bunch of places that relied on transitively including them before. As of this patch, no header file outside src/heap/ includes heap-inl.h. Bug: v8:8562,v8:8499 Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1459659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59617}
-
- 30 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Bug: chromium:926819 Change-Id: I44832f8707c413d40e5632ed39b97624059f1fba Reviewed-on: https://chromium-review.googlesource.com/c/1445891Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59198}
-
- 23 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Also insert NestedVariableDeclarations in the preparser if they occur. This should be uncommon enough to not hurt preparser performance. This will also allow us to stop checking for conflicts on already preparsed code. Since the preparser itself will mainly run off the main thread, this can allow us to free some main-thread time. Bug: v8:7829, v8:8706 Change-Id: I03f2690eb7b22e941995d6f2697e64211ddbeffb Reviewed-on: https://chromium-review.googlesource.com/c/1430069Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59044}
-
- 22 Jan, 2019 2 commits
-
-
Toon Verwaest authored
Change-Id: I907ace62da903dd57cb86b608c0f96ac49623976 Reviewed-on: https://chromium-review.googlesource.com/c/1426130 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58991}
-
Toon Verwaest authored
Change-Id: I2abd9ef9591a5e65dcb3fd0231c8d7467296b576 Reviewed-on: https://chromium-review.googlesource.com/c/1426127Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58990}
-
- 21 Jan, 2019 2 commits
-
-
Toon Verwaest authored
This allows us to stop tracking variables_ in the preparser. This currently makes us track slightly more variables than neccessary in the case `for (var ...` since `var ... of` needs to check conflicts with out simple catch variables. We should probably track the names through a ScopedPtrList instead of a ZonePtrList anyway. Then it won't matter anymore. Change-Id: I64e3f9ab13af8269456439cf15b0bc4d5b9e5380 Reviewed-on: https://chromium-review.googlesource.com/c/1421360Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58960}
-
Toon Verwaest authored
Use variable tracking from ExpressionScopes rather than the PatternRewriter and PreParserExpression::variables_ to declare variables. We only figure out that variables are non-simple parameters once we see the first non-simple parameter. This still uses the pattern rewriter to make variables non-simple (kLet instead of kVar). Change-Id: I4a4ee4852d667c26806bb24896722cfea3e093f2 Reviewed-on: https://chromium-review.googlesource.com/c/1417630Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58954}
-
- 18 Jan, 2019 1 commit
-
-
Camillo Bruni authored
By using a shared byte buffer on the preparser we can drastically reduce the number of ZoneChunkLists. Each PreparseDataBuilder now explicitly keeps track of all inner builders/functions and writes out the data in consecutive order. Change-Id: I0aada118d869b150108c1f633d9960474ad2f9a1 Reviewed-on: https://chromium-review.googlesource.com/c/1411600 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58926}
-
- 15 Jan, 2019 1 commit
-
-
Caitlin Potter authored
Implements https://tc39.github.io/proposal-hashbang/, which simply ignores the first line of a source file if it begins with '#!' (U+0023 U+0021). The test cases are influenced by https://github.com/tc39/test262/pull/1983, which have not been pulled into test262 local-tests due to issues with parseTestRecord. BUG=v8:8523 R=gsathya@chromium.org, adamk@chromium.org, littledan@chromium.org Change-Id: I4ae40222298de768a170c7a1d45fec118ed5713c Reviewed-on: https://chromium-review.googlesource.com/c/1409527 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#58838}
-
- 11 Jan, 2019 2 commits
-
-
Toon Verwaest authored
This unifies the code between parser and preparser, and removes more code from the pattern rewriter. This makes "var x" without assignment and initializer in a loop pessimistically marked as assigned, but that seems pretty unlikely since the variable will just always be undefined. It is also still strictly better than what we had until very recently since any var outside of the function scope used to be marked as assigned. Now we only mark such variables as assigned. Change-Id: Icb37ab249b2a79c2d57a5769bdb964b435cebf62 Reviewed-on: https://chromium-review.googlesource.com/c/1405228Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58736}
-
Leszek Swirski authored
Change-Id: I021776d10dd8ef4bf406f286ee233aff9680a0ec Reviewed-on: https://chromium-review.googlesource.com/c/1384315 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58730}
-
- 10 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Keep track of loop nesting depth on FunctionState and use that to decide whether to mark var as assigned. That also fixes the weird cornercase where a loop body can have multiple expressions due to multiple declarations with independent initializers in a single var-statement. Change-Id: Ia24affde29e22e9464448fd390062f6dd983faf2 Reviewed-on: https://chromium-review.googlesource.com/c/1405037Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58707}
-
- 09 Jan, 2019 1 commit
-
-
Camillo Bruni authored
- Add DataGatheringScope::AddSkippableFunction - Rename preparsed_scope_data_builder to preparse_data_builder Change-Id: Ic882de638bed91a6ca4716f88db859410f1450b8 Reviewed-on: https://chromium-review.googlesource.com/c/1400846Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58673}
-