AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
c140e29b6e
v8/test/cctest/interpreter/bytecode_expectations/ClassFields.golden

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

252 lines
7.4 KiB
Plaintext
Raw Normal View History

[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
#
# Autogenerated by generate-bytecode-expectations.
#
---
wrap: yes
[class] Add harmony-public-fields flag 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}
2017-11-28 09:42:57 +00:00
public fields: yes
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
---
snippet: "
{
class A {
a;
['b'];
}
class B {
a = 1;
['b'] = this.a;
}
new A;
new B;
}
"
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
frame size: 10
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
parameter count: 1
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
bytecode array length: 129
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
bytecodes: [
/* 30 E> */ B(StackCheck),
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(4),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(LdaTheHole),
B(Star), R(8),
B(CreateClosure), U8(2), U8(0), U8(2),
B(Star), R(5),
B(LdaConstant), U8(1),
B(Star), R(6),
B(LdaConstant), U8(3),
B(StaCurrentContextSlot), U8(4),
B(Star), R(9),
B(Mov), R(5), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CallRuntime), U16(Runtime::kDefineClass), R(6), U8(4),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(6),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(7), R(1),
B(CreateClosure), U8(4), U8(1), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(StaNamedProperty), R(5), U8(5), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PopContext), R(4),
B(Mov), R(1), R(2),
B(Ldar), R(closure),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 38 E> */ B(CreateBlockContext), U8(6),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PushContext), R(4),
B(LdaTheHole),
B(StaCurrentContextSlot), U8(4),
B(LdaTheHole),
B(Star), R(8),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CreateClosure), U8(8), U8(4), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(5),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(LdaConstant), U8(7),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(6),
B(LdaConstant), U8(3),
B(StaCurrentContextSlot), U8(4),
B(Star), R(9),
B(Mov), R(5), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CallRuntime), U16(Runtime::kDefineClass), R(6), U8(4),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(6),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(7), R(0),
B(CreateClosure), U8(9), U8(5), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(StaNamedProperty), R(5), U8(5), U8(6),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PopContext), R(4),
B(Mov), R(0), R(3),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 120 S> */ B(Ldar), R(1),
/* 120 E> */ B(Construct), R(1), R(0), U8(0), U8(8),
/* 129 S> */ B(Ldar), R(0),
/* 129 E> */ B(Construct), R(0), R(0), U8(0), U8(10),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(LdaUndefined),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 138 S> */ B(Return),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
]
constant pool: [
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
ONE_BYTE_INTERNALIZED_STRING_TYPE ["b"],
SHARED_FUNCTION_INFO_TYPE,
SYMBOL_TYPE,
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
---
snippet: "
{
class A extends class {} {
a;
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
['b'];
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
}
class B extends class {} {
a = 1;
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
['b'] = this.a;
foo() { return 1; }
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
constructor() {
super();
}
}
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
class C extends B {
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
a = 1;
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
['b'] = this.a;
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
constructor() {
(() => super())();
}
}
new A;
new B;
new C;
}
"
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
frame size: 15
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
parameter count: 1
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
bytecode array length: 244
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
bytecodes: [
/* 30 E> */ B(StackCheck),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Ldar), R(closure),
B(CreateBlockContext), U8(0),
B(PushContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(LdaTheHole),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(StaCurrentContextSlot), U8(4),
B(LdaTheHole),
B(Star), R(14),
B(CreateClosure), U8(3), U8(0), U8(2),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(11),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(LdaConstant), U8(2),
B(Star), R(12),
B(Mov), R(11), R(13),
B(CallRuntime), U16(Runtime::kDefineClass), R(12), U8(3),
B(Star), R(12),
B(CreateClosure), U8(4), U8(1), U8(2),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(Star), R(7),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(LdaConstant), U8(1),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(8),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(LdaConstant), U8(5),
B(StaCurrentContextSlot), U8(4),
B(Star), R(11),
B(Mov), R(7), R(9),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(13), R(10),
B(CallRuntime), U16(Runtime::kDefineClass), R(8), U8(4),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(8),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(9), R(2),
B(CreateClosure), U8(6), U8(2), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(9),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(StaNamedProperty), R(7), U8(7), U8(3),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PopContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(Mov), R(2), R(3),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Ldar), R(closure),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 38 E> */ B(CreateBlockContext), U8(8),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PushContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(LdaTheHole),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(StaCurrentContextSlot), U8(4),
B(LdaTheHole),
B(Star), R(14),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CreateClosure), U8(11), U8(5), U8(2),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(11),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(LdaConstant), U8(10),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(12),
B(Mov), R(11), R(13),
B(CallRuntime), U16(Runtime::kDefineClass), R(12), U8(3),
B(Star), R(12),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CreateClosure), U8(12), U8(6), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(LdaConstant), U8(9),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(8),
B(LdaConstant), U8(5),
B(StaCurrentContextSlot), U8(4),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(11),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CreateClosure), U8(13), U8(7), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(12),
B(Mov), R(7), R(9),
B(Mov), R(13), R(10),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(CallRuntime), U16(Runtime::kDefineClass), R(8), U8(5),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(8),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(9), R(1),
B(CreateClosure), U8(14), U8(8), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(9),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(StaNamedProperty), R(7), U8(7), U8(9),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PopContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(Mov), R(1), R(4),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Ldar), R(closure),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 90 E> */ B(CreateBlockContext), U8(15),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PushContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(LdaTheHole),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(StaCurrentContextSlot), U8(4),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 236 E> */ B(CreateClosure), U8(17), U8(11), U8(2),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(7),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(LdaConstant), U8(16),
[class] Implement super property access in instance fields Bug: v8:5367 Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90 Reviewed-on: https://chromium-review.googlesource.com/789939 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-27 16:19:28 +00:00
B(Star), R(8),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(LdaConstant), U8(5),
B(StaCurrentContextSlot), U8(4),
B(Star), R(11),
B(Mov), R(7), R(9),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(1), R(10),
B(CallRuntime), U16(Runtime::kDefineClass), R(8), U8(4),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(8),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(Mov), R(9), R(0),
B(CreateClosure), U8(18), U8(12), U8(2),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(Star), R(9),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
B(StaNamedProperty), R(7), U8(7), U8(13),
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
B(PopContext), R(6),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(Mov), R(0), R(5),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 329 S> */ B(Ldar), R(2),
/* 329 E> */ B(Construct), R(2), R(0), U8(0), U8(15),
/* 338 S> */ B(Ldar), R(1),
/* 338 E> */ B(Construct), R(1), R(0), U8(0), U8(17),
/* 347 S> */ B(Ldar), R(0),
/* 347 E> */ B(Construct), R(0), R(0), U8(0), U8(19),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
B(LdaUndefined),
[class] Split out static fields into a separate flag 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}
2017-12-21 17:58:28 +00:00
/* 356 S> */ B(Return),
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
]
constant pool: [
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
FIXED_ARRAY_TYPE,
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["b"],
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
SHARED_FUNCTION_INFO_TYPE,
SYMBOL_TYPE,
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
[class] Expand bytecode expectations coverage for class fields Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 12:27:07 +00:00
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
[class] Store class fields initializer on the constructor 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}
2017-11-27 09:56:36 +00:00
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
FIXED_ARRAY_TYPE,
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
Reference in New Issue Copy Permalink