- 29 Jan, 2021 1 commit
-
-
Marja Hölttä authored
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
-
- 28 Jan, 2021 1 commit
-
-
Marja Hölttä authored
This reverts commit f6450b97. Reason for revert: ClusterFuzz bugs Original change's description: > Reland [super] Store home object in Context instead of JSFunction > > 1) Computed property keys (esp functions in them) shouldn't be inside > the object literal scope. > > 2) I was using an imprecise "maybe uses super" and storing it to > preparse data. This won't fly, since it pollutes sister scopes and > leads to confusion wrt whether an object literal needs a home object > or not. Made it precise (mostly cancelling changes in the original CL). > > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for > this_function (which made it used) -> inconsistent scopes between > parsing and preparsing. > > 4) MultipleEntryBlockContextScope was messing up the accumulator > > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Marja Hölttä <marja@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72169} TBR=marja@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72391}
-
- 19 Jan, 2021 2 commits
-
-
Marja Hölttä authored
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72169}
-
Maya Lekova authored
This reverts commit 4d5b878b. Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263 Original change's description: > [super] Store home object in Context instead of JSFunction > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237 > Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72137} TBR=marja@chromium.org,leszeks@chromium.org Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72142}
-
- 18 Jan, 2021 1 commit
-
-
Marja Hölttä authored
This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72137}
-
- 07 Jan, 2021 1 commit
-
-
Daniel Clark authored
There's a bit more work to do to add support for import assertions for dynamic import(). This is the first of a series of changes to do that. This adds parser support for the form of import() that takes import assertions per https://tc39.es/proposal-import-assertions/#prod-ImportCall A future change will pass the assertions expression along to Runtime_DynamicImportCall where the assertions will be unpacked and filtered per Isolate::supported_import_assertions_. Bug: v8:10958 Change-Id: Ib1c80d15ac44923d97c5fdfcc4bd732cb9245cf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612038Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71960}
-
- 25 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I01ffd94290aa5deafa0953a86ff555147b813bf4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557069Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71389}
-
- 10 Aug, 2020 1 commit
-
-
Sathya Gunasekaran authored
Previously, all ThisExpression's had kNoSourcePositions leading to incorrect error messages like this: ➜ d8 -e "function t() { for (const x of this) {} } t();" unnamed:1: TypeError: undefined is not a function function t() { for (const x of this) {} } t(); ^ TypeError: undefined is not a function at t (unnamed:1:11) at unnamed:1:43 This patch allows creation of a ThisExpression with a source position, leading to a better error message: ➜ d8 -e "function t() { for (const x of this) {} } t();" unnamed:1: TypeError: this is not iterable function t() { for (const x of this) {} } t(); ^ TypeError: this is not iterable at t (unnamed:1:32) at unnamed:1:43 This patch does not remove the existing cached version of ThisExpression and instead creates a new one when required. Bug: v8:6513 Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69300}
-
- 30 Jul, 2020 1 commit
-
-
Shu-yu Guo authored
This is a spec bug in V8. Only call expressions literally of the form 'eval(...)' are considered direct. Bug: v8:10688 Change-Id: Ia5ac9992db82cad0ad6870119bd94a0b4daee417 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327752Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#69148}
-
- 16 Jun, 2020 1 commit
-
-
Huáng Jùnliàng authored
Bug: v8:10564 Change-Id: Ibeaa43d9db087d02d8f4d3688fc1f6da41691a60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216931Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#68373}
-
- 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}
-
- 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}
-
- 18 Feb, 2020 1 commit
-
-
Toon Verwaest authored
Bug: v8:8088 Change-Id: Ie92499a43e2286e9bb1c64b0d553a515d74d5aa2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059989Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66313}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 10 Oct, 2019 1 commit
-
-
Joyee Cheung authored
This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
-
- 07 Oct, 2019 1 commit
-
-
Dan Elphick authored
Fixes spurious DCHECK triggering due to bug introduced in https://chromium-review.googlesource.com/c/v8/v8/+/1836258. Bug: chromium:1011596 Change-Id: Ia3b1eb25d326e465b3239f191aad11d90a2e56a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844777Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64125}
-
- 04 Oct, 2019 1 commit
-
-
Dan Elphick authored
This deletes unresolved VariableProxy objects created for labels in the preparser which prevents shadowed variables in enclosing scopes from being context-allocated. Previously this was only done in the full parser, which leads to bytecode mismatches with lazy source positions. Bug: chromium:1009728, v8:8510 Change-Id: If2d0c345346116a7f5aacbcd0cf3638e9f7e04cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1836258Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64104}
-
- 12 Sep, 2019 1 commit
-
-
Francis McCabe authored
Bug: v8:9429 Change-Id: I2b1bc81f72e7cc7657330bd778586f608d62809b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1797659Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63724}
-
- 11 Sep, 2019 1 commit
-
-
Joyee Cheung authored
This patch uses a bit in the Variable bit fields to distinguish static private names from instance private names, so that we can check the conflicts of private accessors that are complementary but with different staticness in the parser, and use this information later when generating code for checking static brands for private method access. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: I8d70600e594e3d07f77ea519751b7ca2e0de87b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781010Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63677}
-
- 06 Sep, 2019 1 commit
-
-
Shu-yu Guo authored
Expressions in class heritage position do not have access to the inheriting class's private names, only its lexical bindings. The parser currently uses the same scope chain for both. This CL makes scopes in class heritage position skip their outer class when resolving private names. Whether a scope needs to skip is kept as a bit on various scope-related data structures. See implementation doc at https://docs.google.com/document/d/1d3o_SQqcICxfjLMw53OOaiIQux0ppNHQJnjZHtCQLwA Bug: v8:9177 Change-Id: I77e491a9d4a261131274f12ddf052af7ac31a921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769486 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#63586}
-
- 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}
-
- 07 Aug, 2019 1 commit
-
-
Gus Caplan authored
Each LHS expression that contains an optional chain of some form is wrapped in an OptionalChain node. This root node allows us to use a single jump location for every individual item in the chain, improving the performance and simplifying the implementation. Bug: v8:9553 Change-Id: I678563928b2dbfd6200bff55801919d4fd816962 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1723359 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63120}
-
- 05 Aug, 2019 1 commit
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
- 30 Jul, 2019 1 commit
-
-
Joyee Cheung authored
This patch adds: - VariableMode::kPrivateMethod - VariableMode::kPrivateSetterOnly - VariableMode::kPrivateGetterOnly - VariableMode::kPrivateGetterAndSetter And replace the previous RequiresBrandCheckFlag by inferring whether the brand check is required from these VariableModes. It is then possible to check duplicate non-complementary accessors in the parsers and throw early errors, and allow complementary accessors to be associated with the same private name variable. This patch also adds the following AssignType: - PRIVATE_METHOD - PRIVATE_GETTER_ONLY - PRIVATE_SETTER_ONLY - PRIVATE_GETTER_AND_SETTER corresponding to the new VariableModes so that it's possible to generate specialized code for different type of private accessor declarations. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62988}
-
- 26 Jul, 2019 1 commit
-
-
Dan Elphick authored
Use the position of commas in arrow expressions to mark the initializer position of any parameters that might have been set in the preceding parameter. To enable this, this makes variable_list_ in ExpressionParsingScope a ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to return references so its elements can be modified in place. This fixes a source of bytecode mismatches when collecting source positions lazily and is a second attempt at fixing this after https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced problems due to destructuring. Bug: chromium:980422, chromium:981701, v8:8510 Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62936}
-
- 17 Jul, 2019 1 commit
-
-
Dan Elphick authored
Mark a couple of constructors as explicit and use the default constructor instead of defining an empty body for PreParserSourceRange. Bug: v8:9396 Change-Id: I60f891245543852d8250105ba7b89620c15204bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706052 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62766}
-
- 08 Jul, 2019 2 commits
-
-
Ross Kirsling authored
This is a reland of 89d93e38 Original change's description: > Reland "Let all early errors be SyntaxErrors." > > This is a reland of 99fd5b9b which includes a missed update to > test/test262/test262.status. > > Implement the spec change from the following TC39 PR: > https://github.com/tc39/ecma262/pull/1527 > > Bug: v8:9326 > Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe > TBR: adamk@chromium.org > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989 > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62500} Bug: v8:9326 Change-Id: Ic30280400dfa5b83a4a397888e563eee479446c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688271Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62553}
-
Clemens Hammacher authored
Cpplint usually checks for non-const reference arguments. They are forbidden in the style guide, and v8 does not explicitly make an exception here. This CL re-enables that warning, and fixes all current violations by adding an explicit "NOLINT(runtime/references)" comment. In follow-up CLs, we should aim to remove as many of them as possible. TBR=mlippautz@chromium.org Bug: v8:9429 Change-Id: If7054d0b366138b731972ed5d4e304b5ac8423bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687891Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62551}
-
- 03 Jul, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit 89d93e38. Reason for revert: Breaks layout tests: https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32929 Original change's description: > Reland "Let all early errors be SyntaxErrors." > > This is a reland of 99fd5b9b which includes a missed update to > test/test262/test262.status. > > Implement the spec change from the following TC39 PR: > https://github.com/tc39/ecma262/pull/1527 > > Bug: v8:9326 > Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe > TBR: adamk@chromium.org > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989 > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62500} TBR=adamk@chromium.org,gsathya@chromium.org,verwaest@chromium.org,rkirsling@gmail.com Change-Id: Ia56dcda6780a2b1249749e1e7978b35b5e33fbcf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9326 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687678Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62509}
-
Ross Kirsling authored
This is a reland of 99fd5b9b which includes a missed update to test/test262/test262.status. Implement the spec change from the following TC39 PR: https://github.com/tc39/ecma262/pull/1527 Bug: v8:9326 Change-Id: Ie3aac60db550e90fb648fc30886a05419fa41afe TBR: adamk@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682989Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62500}
-
- 28 Jun, 2019 1 commit
-
-
Francis McCabe authored
This reverts commit 99fd5b9b. Reason for revert: fails presubmit test: https://ci.chromium.org/p/v8/builders/ci/V8%20Presubmit/5238 and a nosnap test https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34143 Original change's description: > Let all early errors be SyntaxErrors. > > Implement the spec change from the following TC39 PR: > https://github.com/tc39/ecma262/pull/1527 > > Bug: v8:9326 > Change-Id: I9639903b12e7621e323990e2335f00e0313a59c3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643171 > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Adam Klein <adamk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62451} TBR=adamk@chromium.org,verwaest@chromium.org,rkirsling@gmail.com Change-Id: If63b97725e9737ad5a98800e1194caf8e9c1c43d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9326 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682393Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62452}
-