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}
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}
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:
- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.
- This synthetic variable could potentially resolve to an initializer
of an outer class.
For ex:
class X extends Object {
c = 1;
constructor() {
var t = () => {
class P extends Object {
constructor() {
var t = () => { super(); };
t();
}
}
super();
}
t();
}
}
In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.
Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.
For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.
For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:
In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.
This is usually the common case and we don't pay any cost for not using
class fields.
(b) We are in a super() call inside an arrow function in the derived
constructor:
In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.
super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.
Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
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@{#49628}
