- 01 May, 2019 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:5367, v8:5368 Change-Id: I86f25f9f658e21a05604f3014e6ebf74f1a8a1f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590164Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61139}
-
- 16 Oct, 2018 1 commit
-
-
Sathya Gunasekaran authored
Previously when class names were computed and set as part of StoreDataPropertyInLiteral calls, it was observable to static fields as these static fields are initialized right after the classes were constructed but before the class names were installed. This caused the name property to be undefined for this case. Instead, this patch always forces the creation of a name property on the class constructor when static class fields are used. This patch does kill the class boilerplate optimization, but currently all static class fields are installed using a runtime call to CreateDataProperty so this isn't any worse when using static class fields. In the future, this can be optimized away by storing the name on the boilerplate. There is spec discussion here: https://github.com/tc39/proposal-class-fields/issues/85 There isn't a resolution yet, there's still discussion about whether to have the name be undefined always for static class field initializers. But, I don't think that's useful as it would always kill our boilerplate optimization (like this patch does ..., but without the future optimization potential). Bug: v8:5367 Change-Id: I14afdf7ece3f2d9fa3c659d2c0bc3806e0b17abb Reviewed-on: https://chromium-review.googlesource.com/c/1281002Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56686}
-
- 04 Jan, 2018 1 commit
-
-
Sathya Gunasekaran authored
Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
-
- 22 Dec, 2017 1 commit
-
-
Daniel Ehrenberg authored
This patch implements https://github.com/tc39/proposal-class-fields/pull/65 and https://github.com/tc39/proposal-static-class-features/ by splitting out instance and static field declarations into separate flags for the separate proposals. Instance class fields is currently at Stage 3 whereas static class fields is currently at Stage 2. Bug: v8:5367 Change-Id: I133c945fd0b22dc5718c7bb61b10f22348087acd Reviewed-on: https://chromium-review.googlesource.com/839778 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50293}
-
- 01 Dec, 2017 1 commit
-
-
Sathya Gunasekaran authored
Reported by @ziyunfei here: https://twitter.com/ziyunfei/status/936524009528811520 Bug: v8:5367 Change-Id: I2b1bb43dff86f35dec824e275740fce4f0c97b2e Reviewed-on: https://chromium-review.googlesource.com/802877Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49788}
-
- 28 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
Change the existing uses of the harmony-class-fields flag to harmony-public-fields so that we can stage this separately from the upcoming harmony-private-fields to get some clusterfuzz coverage. Bug: v8:5367 Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a Reviewed-on: https://chromium-review.googlesource.com/792940 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49661}
-
- 27 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously we only created synthetic variables in the parser and not in the preparser, causing mismatch in the preparsed scope data. This patch creates the variables in both parsers. Bug: v8:5367 Change-Id: I9c511d0b9212bd36816956b06dc204b0b5920e1c Reviewed-on: https://chromium-review.googlesource.com/789848 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49637}
-
- 08 Nov, 2017 2 commits
-
-
Sathya Gunasekaran authored
StoreDataPropertyInLiteral doesn't throw (because the previous uses of this didn't throw), but class fields can throw on defining the property which means we can't use this. Changing to CreateDataProperty runtime call instead. Bug: v8:5367 Change-Id: I1ab45413b121972dd18fe2b35a0cedd8efe0e0bf Reviewed-on: https://chromium-review.googlesource.com/757824 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49239}
-
Sathya Gunasekaran authored
Creates a new initializer function to instantiate instance class fields in a base class. An initializer function (similar to the one created for static fields) is created during class declaration and assigned to a synthetic context allocated variable. This function is loaded from the variable during instantiation (when the constructor is run) and run. Bug: v8:5367 Change-Id: Ie11c2183b3001234ae41d7bcc2cb9b02c0764ab5 Reviewed-on: https://chromium-review.googlesource.com/754445 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49207}
-
- 03 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
This patch evaluates computed properties in the order of declaration during class definition time. This patch creates a synthetic variable to store the result of evaluating a computed property and then looks this up in the initializer function. Bug: v8:5367 Change-Id: I4182c6a01196d2538991818142890f6afb0e532b Reviewed-on: https://chromium-review.googlesource.com/752567Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49115}
-
- 27 Oct, 2017 1 commit
-
-
Sathya Gunasekaran authored
Instead of creating a runtime call for the static class field initializer in the AST, we do it in the bytecode generator. This adds the initializer function to the ClassLiteral AST node. Bug: v8:5367 Change-Id: Iffaa6531511023812011ee19fc96cea9e5c9d3f3 Reviewed-on: https://chromium-review.googlesource.com/736315Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49008}
-
- 23 Oct, 2017 1 commit
-
-
Sathya Gunasekaran authored
This patch implements the runtime semantics of static public class fields. Adds a new InitializeClassFieldsStatement AST node that contains all the static class fields and their initializers. ClassLiteral is now desugared to be included in a do-exp that calls an initializer function which contains this new AST node. Bug: v8:5367 Change-Id: I3574e4c685f1c039de42521c122e24f8d28e5d6c Reviewed-on: https://chromium-review.googlesource.com/714817Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#48835}
-