- 27 Aug, 2021 1 commit
-
-
Leszek Swirski authored
StaGlobal didn't write the accumulator, but the baseline implementation assumed that it could preserve the accumulator by taking the return value of the StoreGlobalIC. This almost always worked, except for setters on the global object. Fix this by marking StaGlobal as clobbering the accumulator, same as StaNamedProperty (StaNamedProperty needs to do this anyway to avoid inlined setters from needing to create accumulator-preserving frames; StaGlobal would have needed the same thing if we'd ever inlined setters for it). Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the baseline compiler, which checks if the accumulator value is preserved across non-accumulator-writing bytecodes. This found a (benign) bug with ForInPrepare, so fix that too. Fixed: chromium:1242306 Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#76525}
-
- 18 Aug, 2021 1 commit
-
-
Shu-yu Guo authored
Bug: v8:11852 Change-Id: I1d3c01b827e847bb7edcd2ebe7d3b340f7d53069 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097473 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#76355}
-
- 13 Aug, 2021 1 commit
-
-
Nicolò Ribaudo authored
Previously V8 was reusing the error fur duplicate declarations, using the private name for class fields or the class name for class methods as the redeclared identifier. class A { constructor(o) { return o } } class B extends A { #x } class C extends A { #x() {} } let D = (0, class extends A { #x() {} }); new B(new B({})) // Identifier '#x' has already been declared new C(new C({})) // Identifier 'C' has already been declared new D(new D({})) // Identifier '' has already been declared This patch changes it to use error messages that better explain what's happening: new B(new B({})) // Cannot initialize #x twice on the same object new C(new C({})) // Cannot initialize private methods of // class C twice on the same object new D(new D({})) // Cannot initialize private methods of // class anonymous twice on the same object I initially tried to use the same message for both fields and methods, but the problem with that is that when initializing fields we only have access to the field name, while when initializing methods we only have access to the class name (using the "private brand" symbol). However, almost all the error messages are different for private fields and for methods so this shouldn't be a problem. Bug: v8:12042 Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Joyee Cheung <joyee@igalia.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76279}
-
- 08 Jul, 2021 2 commits
-
-
Patrick Thier authored
This is a reland of 819c3ae2 Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75645}
-
Leszek Swirski authored
This reverts commit 819c3ae2. Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75626}
-
- 07 Jul, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of 8b18c5e6 Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75604}
-
- 06 Jul, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 8b18c5e6. Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75577}
-
Patrick Thier authored
This is a reland of 24c626c1 Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75571}
-
- 21 Jun, 2021 1 commit
-
-
Bill Budge authored
This reverts commit 24c626c1. Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail): https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109? Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#75282}
-
- 18 Jun, 2021 1 commit
-
-
Patrick Thier authored
Only print the property name when accessing null/undefined if we can convert it to a string without causing side effects. If we can't, omit the property name in the error message. This should avoid confusion when the key is an object with toString(). E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object Object]' anymore, which was misleading since the property accessed would be 'a', but we can't evaluate the key without side effects. Bug: v8:11365 Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75250}
-
- 21 May, 2021 1 commit
-
-
Ross McIlroy authored
They have been disabled for some time and are superseeded by lazy feedback vector allocation. Change-Id: Iafc3989b0c1f866ce7d6295d9b13ccaa5ef1c115 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905609Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74711}
-
- 19 May, 2021 1 commit
-
-
Marja Hölttä authored
The logic is different for shared and non-shared memory, so it's cleaner to have different functions for them. Bug: v8:11111 Change-Id: I95d43b54c207b8059ea59d6d0f873623de946be3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903152 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74656}
-
- 10 May, 2021 1 commit
-
-
Marja Hölttä authored
Detailed list of changes: https://docs.google.com/document/d/15i4-SZDzFDW7FfclIYuZEhFn-q-KpobCBy23x9zZZLc/edit?usp=sharing Bug: v8:11111 Change-Id: I931003bd4552cf91d57de95af04a427a9e6d6ac9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814259Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74459}
-
- 06 May, 2021 1 commit
-
-
Ross McIlroy authored
Order the bytecodes to enable range-based checks for IsWithoutExternalSideEffects. Also remove the now unecessary macro definitions for Jump bytecodes. BUG=v8:9684 Change-Id: Id2d7e2e0141b57864c65a752bc233f004f86f760 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2875208 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#74397}
-
- 30 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we'd attach source positions to implicit returns that are generated when leaving an async function with a promise rejection. This was due to the use of `kNoSourcePosition` on the `end_position` in the `ReturnStatement` nodes as indicator to pick the return position from the function literal, instead of really not putting a source position on that specific `Return` bytecode. This CL adds a dedicated marker to `ReturnStatement` to express that the `BytecodeGenerator` should put the return position from the function literal there instead of overloading the meaning of `kNoSourcePosition`. Bug: chromium:901819, chromium:782461 Fixed: chromium:1199919, chromium:1201706 Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74301}
-
- 19 Mar, 2021 2 commits
-
-
Shu-yu Guo authored
Bug: v8:11573 Change-Id: Iab32d07443298bcd39c470ad92c5ce6db0a2b580 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2770603 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73550}
-
Shu-yu Guo authored
Calls with a spread expression in a non-final position get transformed to calls to Reflect.apply. This transformation is currently done in the parser, which does not compose well with other features (e.g. direct eval checking, optional chaining). Do this transform in the BytecodeGenerator instead. Bug: v8:11573, v8:11558, v8:5690 Change-Id: I56c90a2036fe5b43e0897c57766f666bf72bc3a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2765783 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73534}
-
- 02 Mar, 2021 1 commit
-
-
Benedikt Meurer authored
Be explicit about source positions for `Return`s in the BytecodeGenerator, and only do self-healing explicitly in the `ReturnStatement` translation, where an end position of `kNoSourcePosition` is turned into the return position of the function literal. This allows us to reason more easily about which `Return`s actually receive a meaningful source position, and in particular it allows us to construct the internal `Return`s for `yield` and `yield*` with no source position attached to them. Previously they'd get the source position for the implicit (final) return attached to it, which confused the debugger and led to breakpoints being set in the completely wrong spot. Considering the simplified example ``` function* foo(){ var a = 1; } ``` this would previously generate the following bytecode ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 30 S> 38 : Return <=========================== internal Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` where everything between offset 4 and 42 corresponds to the implicit yield at the beginning of every generator function, in particular the code between 20 and 42 corresponds to that initial yields resumption logic. Notice how the internal Return at offset 38 gets assigned the source position of the function literal (the same as the implicit return at the end). This confuses the debugger quite a bit when trying to set a breakpoint on the closing brace, since it's going in bytecode order and will thus discover the `Return` at offset 38 first (matching the source position 30 it's currently looking for) and setting the breakpoint there. This `Return` bytecode however is only executed when the generator is resumed via `GeneratorPrototype.return()`, and it'll not hit when the developer uses the generator normally, which is not the desired behavior and extremely confusing (especially since stepping on the other hand works as expected). With this patch, we no longer slap a source position (and in particular not the function literal's return position) onto these internal `Return`s as you can see from the generated bytecode below: ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 38 : Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` This also allows us to remove the break position finding hack that was kept in BreakIterator::BreakIndexFromPosition() for generators and modules. Fixed: chromium:901819 Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73119}
-
- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of cf93071c Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
- 16 Feb, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
- 09 Feb, 2021 1 commit
-
-
Shu-yu Guo authored
Implements https://github.com/tc39/ecma262/issues/2034 Currently the token sequence `for (async of` is ambiguous. It can be the prefix for either `(async of => {};;);` or `for (async of foo);`. This CL disallows the token sequence. Note that `for await (async of` is still allowed, since there is no C-style `for await (;;)`, and thus no ambiguity. Bug: v8:11412 Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72607}
-
- 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}
-
- 26 Jan, 2021 1 commit
-
-
Daniel Clark authored
This change completes support for import assertions for dynamic import(). A new version of the HostImportModuleDynamically callback taking import assertions is added to the public API. The name is very verbose; we could consider removing the "ImportAssertions" part when the old API is removed. Bytecode generation is updated to pass the assertions, if present, to Runtime_DynamicImportCall. Isolate::RunHostImportModuleDynamicallyCallback extracts the assertions from the options bag, filters out the assertions not present in the list specified by the host in HostGetSupportedImportAssertions, and sorts them by code point order of the keys per https://tc39.es/proposal-import-assertions/#sec-import-call-runtime-semantics-evaluation. The resulting array is passed to the host in the callback. Bug: v8:10958 Change-Id: I931df00f954a9f9c65bff5bcf461ba1c8f11e94e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620578 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72307}
-
- 22 Jan, 2021 1 commit
-
-
Marja Hölttä authored
Bug: v8:9237 Change-Id: I60b016617d468e6a04ef48998e59c80f58d16863 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642245Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72246}
-
- 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}
-
- 17 Dec, 2020 1 commit
-
-
Patrick Thier authored
When we know a value passed to BytecodeArrayBuilder::LoadLiteral(double) can be encoded as a Smi, we create LdaSmi instead of LdaConstant. Driven by a forgotten Smi::FromInt() in BytecodeGenerator, also fixed in this CL. Bug: v8:11278 Change-Id: I4a1ad48e2c9aff8391113812e34dae838a1a38d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595437Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#71827}
-
- 12 Nov, 2020 1 commit
-
-
Shu-yu Guo authored
It's shipped since M84. Bug: v8:8330 Change-Id: Ia643948c0de83fc9a8faf7307b7fd86a1e117dc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2511034 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71166}
-
- 29 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Fix super calls so that arguments are evaluated before the super constructor is checked to be in fact a constructor. A new bytecode is introduced to split the IsConstructor check out from the current GetSuperConstructor bytecode. Bug: v8:10111 Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#70881}
-
- 21 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Implements https://github.com/tc39/ecma262/pull/2154, which allows module export names to be string literals. Semantics highlights: - It is a SyntaxError for string literal export names to have unpaired UTF16 surrogates. - It is a SyntaxError for string literal export names to be used as the local name without being followed by a 'from' clause. For example, `export { "foo" }` and `export { "foo" as "bar" }` are errors, but `export { "foo" } from "./module.js"` is allowed. The remaining failing test262 test is wrong: https://github.com/tc39/test262/issues/2866 Bug: v8:10964 Change-Id: Ib3e06e1ee6b3f1b60ed7f24e21902e17ddfc0351 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482335 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70692}
-
- 19 Oct, 2020 1 commit
-
-
Daniel Clark authored
Parse the AssertEntries in an import assertion clause, storing them in a map. Plumb them through the parser to the appropriate SourceTextModuleDescriptor methods. The next change will plumb them into the SourceTextModuleDescriptor's ModuleRequestMap and through to SourceTextModuleInfo::New. Bug: v8:10958 Change-Id: I19c31090520f14f94d014e760f5fe372bf773fc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482326Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70622}
-
- 30 Sep, 2020 1 commit
-
-
Jakob Kummerow authored
Sorting a TypedArray with a custom compare function requires us to copy the array's contents to a FixedArray. When the TypedArray is larger than FixedArray::kMaxLength, we should throw a RangeError rather than crashing with an OOM message. Fixed: v8:10931 Change-Id: I8a27cc0ac80a9172bc5e8e154fdf4ccce5974317 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440575 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70232}
-
- 25 Sep, 2020 1 commit
-
-
Gus Caplan authored
This fixes the logic in the desugaring of destructuring assignments. In particular, a spread element would not check if previous `next` results had already been done, and would always call `next()` again. Change-Id: I1bd384678722e6cf51c5777fc3b0dd965360291a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2430488 Commit-Queue: Gus Caplan <snek@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70144}
-
- 23 Sep, 2020 1 commit
-
-
Gus Caplan authored
Bug: v8:9344, v8:6513 Change-Id: I1854e483515e7da99192367b6764a0ec7c8b41d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411687Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Gus Caplan <snek@chromium.org> Cr-Commit-Position: refs/heads/master@{#70099}
-
- 11 Sep, 2020 1 commit
-
-
Frank Tang authored
Bug: v8:10880 Change-Id: I7a9ba96e4b0c83565c4749101082c661e21d5ef1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400598Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Frank Tang <ftang@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#69844}
-
- 02 Sep, 2020 2 commits
-
-
HyeockJinKim authored
During spread operation, after VisitForAccumulatorValue, set the position of the current expression again Bug: chromium:929844 Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531 Commit-Queue: HyeockJin Kim <kherootz@gmail.com> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#69677}
-
Victor Gomes authored
This adds the argument count (as intptr) to the standard frame. StandardFrames are now in the same shape as OptimizedFrames. The argument count in the stack will be used to tear down the arguments when we remove the arguments adaptor frame. Change-Id: If9cc2946321bc1bb0abb776521e2d5b683ab0532 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312783 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69663}
-