- 25 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
The deprecated legacy FinalizationGroup APIs are left unchanged for compat. Bug: v8:8179 Change-Id: I9bdcaa92360db318c96fc8524c04163ece25118e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071236 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#66437}
-
- 24 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Currently implicit returns do not correctly resolve the async generator objects. This is observable via AsyncGenerator#throw as the implicit return won't override the rejection. Bug: v8:10238 Change-Id: I012fc3507d1e4106e7f35b21275be180a6e274c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065343Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66413}
-
- 12 Feb, 2020 2 commits
-
-
Shu-yu Guo authored
A FinalizationGroup that needs cleanup should not artificially prolong its lifetime by being on the dirty list. R=ulan@chromium.org Bug: v8:8179 Change-Id: I19f102d154a9ac43b549b7d833d0c3ca7e61c6d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051562Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66251}
-
Shu-yu Guo authored
R=ulan@chromium.org Bug: v8:8179 Change-Id: I2ca1c0fd5f02e638b082a2283a8a0c816764c101 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050092Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66249}
-
- 10 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Deprecate the following explicit FinalizationGroup APIs in favor of automatic handling of FinalizationGroup cleanup callbacks: - v8::Isolate::SetHostCleanupFinalizationGroupCallback - v8::FinaliationGroup::Cleanup If no HostCleanupFinalizationGroupCallback is set, then FinalizationGroup cleanup callbacks are automatically scheduled by V8 itself as non-nestable foreground tasks. When a Context being disposed, all FinalizationGroups that are associated with it are removed from the dirty list, cancelling scheduled cleanup. This is a reland of 31d8ff7a Bug: v8:8179, v8:10190 Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66208}
-
- 09 Feb, 2020 1 commit
-
-
Michael Achenbach authored
This reverts commit 31d8ff7a. Reason for revert: https://crbug.com/v8/10190 Original change's description: > [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8 > > Deprecate the following explicit FinalizationGroup APIs in favor of > automatic handling of FinalizationGroup cleanup callbacks: > - v8::Isolate::SetHostCleanupFinalizationGroupCallback > - v8::FinaliationGroup::Cleanup > > If no HostCleanupFinalizationGroupCallback is set, then > FinalizationGroup cleanup callbacks are automatically scheduled by V8 > itself as non-nestable foreground tasks. > > When a Context being disposed, all FinalizationGroups that are > associated with it are removed from the dirty list, cancelling > scheduled cleanup. > > Bug: v8:8179 > Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66184} TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8179 Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66190}
-
- 08 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Deprecate the following explicit FinalizationGroup APIs in favor of automatic handling of FinalizationGroup cleanup callbacks: - v8::Isolate::SetHostCleanupFinalizationGroupCallback - v8::FinaliationGroup::Cleanup If no HostCleanupFinalizationGroupCallback is set, then FinalizationGroup cleanup callbacks are automatically scheduled by V8 itself as non-nestable foreground tasks. When a Context being disposed, all FinalizationGroups that are associated with it are removed from the dirty list, cancelling scheduled cleanup. Bug: v8:8179 Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66184}
-
- 07 Feb, 2020 1 commit
-
-
Mythri A authored
We used to optimize functions that are expected to executed only once by not allocating feedback slots for some of the bytecodes. This would help in reducing the memory and avoiding initializing feedback that would be never used. With lazy feedback allocation, we don't allocate feedback vectors for most of such functions anyway. The generated bytecode for oneshot optimized functions is different and if we don't properly track this information we might end up generating different bytecode for the same function. This could causes problems when there is a mismatch between the feedback slots used by the new bytecode and the old bytecode. Since we potentially get most of the benefits of this optimization with lazy feedback vector allocation we can simplify the code by disabling this optimization. Bug: chromium:1045824 Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#66172}
-
- 13 Jan, 2020 1 commit
-
-
legendecas authored
Fixed: v8:10083 Change-Id: I50e01022b1d1219ad8b31dd71f58f5bc9c9d10bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987845 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65719}
-
- 26 Dec, 2019 1 commit
-
-
Joshua Litt authored
Fixes a potential overflow when using the runtime's StringCompareSequence by checking the string length first. Bug: chromium:1032906 Change-Id: I7cb94473ae8331dd2ecf1fa98034829bebf8a9ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973936 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65558}
-
- 19 Dec, 2019 2 commits
-
-
Shu-yu Guo authored
Change unregister tokens to be held weakly instead of strongly. This enables the use case for an object to be used as its own unregister token. To avoid using an ephemeron table, FinalizationGroup's key_map is changed to key off unregister tokens' identity hashes. Because hashes may collide, a single key list may rarely contain multiple tokens. When a FinalizationGroup WeakCell's token becomes unreachable, during GC, it is removed from the the doubly linked key list and removed from the key map if it had a unique key. Bug: v8:8179 Change-Id: If88fd2ab196e3f9a287990ae345117a0abb2f04d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970493 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65532}
-
Shu-yu Guo authored
The spec was normatively changed to simplify var scopes for parameter expressions. Previously there was a per-parameter var scope in sloppy mode so direct evals could introduce vars that did not escape the parameter position. That semantics is complex both for the programmer and implementation and has resulted in bugs in the past. Furthermore, it has never been fully interoperable (with Safari in particular). The spec was instead changed to be simpler: to have a single var scope for sloppy evals in parameters that encloses the parameter scope and body scope. This simplification lets us remove expression-scope-reparenter. Drive-by removal of stale reference to PatternRewriter. Bug: v8:7532 Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#65517}
-
- 29 Nov, 2019 1 commit
-
-
Shu-yu Guo authored
Correctly passing the receiver depends on the Call AST node's type. Calling a parenthesized optional chain expression is parsed as a Call of an OptionalChain of a Property. Currently the computation of the type does not take optional chains of property loads into consideration, so calls of parenthesized optional chain expressions always get passed an undefined receiver. Bug: v8:10024 Change-Id: I904b0eeca2df30160def674fb32adf821403aef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938571Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#65252}
-
- 27 Nov, 2019 1 commit
-
-
Joshua Litt authored
Bug: chromium:1028475 Change-Id: I0101930e01d41b0f29fa28a257e3dc720069faff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936835Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65214}
-
- 25 Nov, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9548 Change-Id: I0842ca8ce49ea3a831ae4f168c6dfa7d65dfe063 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930173Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65156}
-
- 21 Nov, 2019 1 commit
-
-
Joshua Litt authored
This is a reland of f2a74165 Original change's description: > [regexp] Re-execute regexp when '.indices' is accessed. > > Instead of storing a pointer to the last_match_info, which may > change, this cl modifies JSRegExpResult to store a pointer to > the original JSRegExp which generated it, as well as additional > data needed to re-execute the match. > > Basically a straight copy and tidy off jgruber@'s prototype: > https://chromium-review.googlesource.com/c/v8/v8/+/1876810 > > Bug: v8:9548 > Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129 > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65053} Bug: v8:9548 Change-Id: Ieeba4b1ae59ef0c7946d654dc314adfae09d24b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925554Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65096}
-
- 20 Nov, 2019 1 commit
-
-
Joshua Litt authored
This reverts commit f2a74165. Reason for revert: Clusterfuzz Bug: chromium:1026479 Original change's description: > [regexp] Re-execute regexp when '.indices' is accessed. > > Instead of storing a pointer to the last_match_info, which may > change, this cl modifies JSRegExpResult to store a pointer to > the original JSRegExp which generated it, as well as additional > data needed to re-execute the match. > > Basically a straight copy and tidy off jgruber@'s prototype: > https://chromium-review.googlesource.com/c/v8/v8/+/1876810 > > Bug: v8:9548 > Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129 > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65053} TBR=jgruber@chromium.org,joshualitt@chromium.org Change-Id: I6294e3d7ac0b3e2bd9404697823b8d3cc2545c16 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9548 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925651Reviewed-by: Joshua Litt <joshualitt@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65057}
-
- 19 Nov, 2019 1 commit
-
-
Joshua Litt authored
Instead of storing a pointer to the last_match_info, which may change, this cl modifies JSRegExpResult to store a pointer to the original JSRegExp which generated it, as well as additional data needed to re-execute the match. Basically a straight copy and tidy off jgruber@'s prototype: https://chromium-review.googlesource.com/c/v8/v8/+/1876810 Bug: v8:9548 Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65053}
-
- 14 Nov, 2019 1 commit
-
-
Igor Sheludko authored
... that started failing on AIX where the allocation of a huge ArrayBuffer succeeds. Bug: v8:4153 Change-Id: I322c71e01edccb254a523f7f85817971b6c68242 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914561Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64960}
-
- 05 Nov, 2019 1 commit
-
-
Joshua Litt authored
Implements TC39 String.prototype.replaceAll as a torque builtin per the https://github.com/tc39/proposal-string-replaceall proposal. Note: matchAll changes were already added to V8 in https://chromium-review.googlesource.com/c/v8/v8/+/1846067 Bug: v8:9801 Change-Id: Ib8158eb39c854202d04710d6f9c33dcdd93fad93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877054 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64785}
-
- 04 Nov, 2019 1 commit
-
-
Joshua Litt authored
This reverts commit d4574d18. Reason for revert: In addition to the earlier octane regression, this cl also created a regression in desktop browsing Bug: chromium:1019601 Original change's description: > Reland "[regexp] Clone match info for match indices." > > This reverts commit d7793c06. > > Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact. > > Original change's description: > > Revert "[regexp] Clone match info for match indices." > > > > This reverts commit dfd9ceb9. > > > > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749 > > > > Original change's description: > > > [regexp] Clone match info for match indices. > > > > > > The current behavior for generating match indices simply stashes a > > > pointer to the match info and then constructs the indices lazily. > > > However, it turns out the match info object used to create the result > > > object is the regexp_last_match_info living on native context, and thus > > > it can change between the creation of the result object and the generation > > > of indices. This cl clones the match info which will be safer. > > > > > > Bug: v8:9548 > > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585 > > > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#64356} > > > > TBR=jgruber@chromium.org,joshualitt@chromium.org > > > > # Not skipping CQ checks because original CL landed > 1 day ago. > > > > Bug: v8:9548, chromium:1015749 > > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236 > > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64407} > > TBR=jgruber@chromium.org,joshualitt@chromium.org > > > Bug: v8:9548, chromium:1015749 > Change-Id: I151511307e3d8752fdbde4b8247514031b141b08 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587 > Reviewed-by: Joshua Litt <joshualitt@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64587} TBR=jgruber@chromium.org,joshualitt@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9548, chromium:1015749 Change-Id: Ie5a8e55338728aae33102d82e60a188f6440e8f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898030Reviewed-by: Joshua Litt <joshualitt@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64749}
-
- 28 Oct, 2019 1 commit
-
-
Joshua Litt authored
This reverts commit d7793c06. Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact. Original change's description: > Revert "[regexp] Clone match info for match indices." > > This reverts commit dfd9ceb9. > > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749 > > Original change's description: > > [regexp] Clone match info for match indices. > > > > The current behavior for generating match indices simply stashes a > > pointer to the match info and then constructs the indices lazily. > > However, it turns out the match info object used to create the result > > object is the regexp_last_match_info living on native context, and thus > > it can change between the creation of the result object and the generation > > of indices. This cl clones the match info which will be safer. > > > > Bug: v8:9548 > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585 > > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64356} > > TBR=jgruber@chromium.org,joshualitt@chromium.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: v8:9548, chromium:1015749 > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64407} TBR=jgruber@chromium.org,joshualitt@chromium.org Bug: v8:9548, chromium:1015749 Change-Id: I151511307e3d8752fdbde4b8247514031b141b08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587Reviewed-by: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64587}
-
- 22 Oct, 2019 1 commit
-
-
Joshua Litt authored
Currently, RegExpResult builds match indices lazily using data stored in hidden internal fields on the result object itself. Unfortunately, if an internal field is deleted, it can cause these hidden fields to migrate to a dictionary, making indexed lookup unsafe. This CL forces slow but safe lookup for these fields when lazily building indices. Bug: v8:9548, chromium:1013133 Change-Id: Ide87d9ca6a73644ced3de8e35ecac26330d365e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871756Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64474}
-
- 21 Oct, 2019 2 commits
-
-
Joshua Litt authored
Bug: chromium:1014458 Change-Id: I9e5e83da4452e9953218335353047f41c18f68fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864333 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#64428}
-
Jakob Gruber authored
This reverts commit dfd9ceb9. Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749 Original change's description: > [regexp] Clone match info for match indices. > > The current behavior for generating match indices simply stashes a > pointer to the match info and then constructs the indices lazily. > However, it turns out the match info object used to create the result > object is the regexp_last_match_info living on native context, and thus > it can change between the creation of the result object and the generation > of indices. This cl clones the match info which will be safer. > > Bug: v8:9548 > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585 > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64356} TBR=jgruber@chromium.org,joshualitt@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9548, chromium:1015749 Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64407}
-
- 17 Oct, 2019 1 commit
-
-
Joshua Litt authored
The current behavior for generating match indices simply stashes a pointer to the match info and then constructs the indices lazily. However, it turns out the match info object used to create the result object is the regexp_last_match_info living on native context, and thus it can change between the creation of the result object and the generation of indices. This cl clones the match info which will be safer. Bug: v8:9548 Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64356}
-
- 16 Oct, 2019 2 commits
-
-
Joshua Litt authored
This cl modifies RegExp.prototype.matchAll to throw on non-global regexps. Relevant pull request: https://github.com/tc39/ecma262/pull/1716 Bug: v8:9800 Change-Id: Ie963c1c00441f1c4e2b975c3bab77cca902c7ebc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846067Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64318}
-
Jakob Gruber authored
Named capture properties on the groups object should be ordered by the capture index (and not alpha-sorted). This was accidentally broken in https://crrev.com/c/1687413. Bug: v8:9822,v8:9423 Change-Id: Iac6f866f077a1b7ce557ba47e8ba5d7e7014b3ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864829 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64306}
-
- 10 Oct, 2019 2 commits
-
-
Joyee Cheung authored
This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 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@{#64225}
-
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}
-
- 24 Sep, 2019 1 commit
-
-
Joshua Litt authored
Adds support for parsing top level await to V8, as well as many tests. This is the final cl in the series to add support for top level await to v8. Spec is here: https://tc39.es/proposal-top-level-await/#sec-execute-async-module Bug: v8:9344 Change-Id: Ie8f17ad8c7c60d1f6996d134ae154416cc1f31e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1703878Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63946}
-
- 20 Sep, 2019 1 commit
-
-
Joshua Litt authored
This cl adds support for top level await to d8, but still does not allow top level await through parsing. Unfortunately, due to that restriction this cl has no automated tests, but I added a 'top-level-await' variant and manually confirmed it passes locally. Bug: v8:9344 Change-Id: I3528442768107f5ad1ed1e9e947cfceae91c0cc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808483 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63909}
-
- 16 Sep, 2019 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770,v8:9666 Change-Id: I7b7652887d6b60fbb80e1100834bc7c9df0544d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792909 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63801}
-
- 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}
-
- 05 Sep, 2019 1 commit
-
-
Joshua Litt authored
Implements match indices for regexp, as specified by https://github.com/tc39/proposal-regexp-match-indices, a stage 3 TC39 proposal. This implementation is hidden behind the '--harmony-regexp-match-indices' flag. Regexp match indices extends the JSRegExpResult object with an array of indices of matches, as well as a dictionary of capture names to match indices. Bug: v8:9548 Change-Id: Ia9efcee00d997dda6158539b8d0f4c4e5965e5e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771379 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63581}
-
- 30 Aug, 2019 1 commit
-
-
Joyee Cheung authored
This patch implements the access of private accessors by loading the referenced component from the AccessorPair associated with private name variables. It also makes the error messages for invalid kind of private accessor access more specific. Bug: v8:8330 Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Change-Id: I6d441cffb85f8d9cd0417ec9b6ae20f3e34ef418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695205Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63474}
-
- 23 Aug, 2019 3 commits
-
-
Joshua Litt authored
This reverts commit 9460101c. Reason for revert: Causes confusion on Blink side, as it introduces an object with >=2 internal fields that is not a wrapper (see bug). Bug: chromium:996681 Change-Id: I275b5a064a4ee8c73c05f97be322924a3bc5370e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769148Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63386}
-
Andreas Haas authored
This reverts commit 5db04cc0. Reason for revert: <INSERT REASONING HERE> Original change's description: > Revert "[regexp] Only append to JSRegExpResult's initial map if we add descriptor" > > This reverts commit dc1cc223. > > Revert "[regexp] Implement the match indices proposal" > > This reverts commit 9460101c. > > Reason for revert: Causes confusion on Blink side, as it introduces > an object with >=2 internal fields that is not a wrapper (see bug). > > Bug: chromium:996681 > Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63376} TBR=yangguo@chromium.org,sigurds@chromium.org,joshualitt@chromium.org Change-Id: Ic58fc3fc83faaf86bd895da29eacb7d51c443beb No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:996681 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768584Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63379}
-
Joshua Litt authored
This reverts commit dc1cc223. Revert "[regexp] Implement the match indices proposal" This reverts commit 9460101c. Reason for revert: Causes confusion on Blink side, as it introduces an object with >=2 internal fields that is not a wrapper (see bug). Bug: chromium:996681 Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63376}
-