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

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

262 lines
8.0 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] 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 {
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
#a;
constructor() {
this.#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
}
class B {
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +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
}
new A;
new B;
}
"
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
frame size: 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
parameter count: 1
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
bytecode array length: 131
[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(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
B(Star), R(4),
B(LdaConstant), U8(2),
B(Star), R(4),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(4), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), 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(LdaTheHole),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(6),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(3), U8(0), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), 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(LdaConstant), U8(1),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(4),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(3),
B(Star), R(4),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
B(CreateClosure), U8(4), U8(1), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(5),
B(StaNamedProperty), R(3), U8(5), U8(0),
B(PopContext), R(2),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(3), R(0),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
/* 38 E> */ B(CreateBlockContext), U8(6),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(2),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
B(Star), R(4),
B(LdaConstant), U8(2),
B(Star), R(4),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(4), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), 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(LdaTheHole),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(6),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
B(CreateClosure), U8(8), U8(2), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(3),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
B(LdaConstant), U8(7),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(4),
B(Mov), R(3), R(5),
B(CallRuntime), U16(Runtime::kDefineClass), R(4), U8(3),
B(Star), R(4),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
B(CreateClosure), U8(9), U8(3), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(5),
B(StaNamedProperty), R(3), U8(5), U8(2),
B(PopContext), R(2),
B(Mov), R(3), R(1),
/* 136 S> */ B(Ldar), R(0),
/* 136 E> */ B(Construct), R(0), R(0), U8(0), U8(4),
/* 145 S> */ B(Ldar), R(1),
/* 145 E> */ B(Construct), R(1), R(0), U8(0), 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(LdaUndefined),
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
/* 154 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: [
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_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
FIXED_ARRAY_TYPE,
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["#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
SHARED_FUNCTION_INFO_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
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
SYMBOL_TYPE,
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_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
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 {} {
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
#a;
constructor() {
super();
this.#a = 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
}
class B extends class {} {
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
#a = 1;
#b = this.#a;
foo() { return this.#a; }
bar(v) { this.#b = v; }
[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] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
this.foo();
this.bar(3);
[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
class C extends B {
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
#a = 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
constructor() {
(() => super())();
}
}
new A;
new B;
new C;
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
};
[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] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
frame size: 12
[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] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
bytecode array length: 268
[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(CreateBlockContext), U8(0),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
B(Star), R(5),
B(LdaConstant), U8(2),
B(Star), R(5),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(5), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), U8(3),
[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] 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] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(4), U8(0), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(8),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(3),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(9),
B(Mov), R(8), R(10),
B(CallRuntime), U16(Runtime::kDefineClass), R(9), U8(3),
B(Star), R(9),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(5), U8(1), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), 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(LdaConstant), U8(1),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(5),
B(Mov), R(4), R(6),
B(Mov), R(10), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
B(Star), R(5),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
B(CreateClosure), U8(6), U8(2), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(6),
B(StaNamedProperty), R(4), U8(7), U8(0),
B(PopContext), R(3),
B(Mov), R(4), R(0),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
/* 38 E> */ B(CreateBlockContext), U8(8),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
B(Star), R(5),
B(LdaConstant), U8(2),
B(Star), R(5),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(5), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), U8(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(10),
B(Star), R(5),
B(LdaConstant), U8(10),
B(Star), R(5),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(5), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), U8(4),
[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] 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] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(12), U8(3), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(8),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(11),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(9),
B(Mov), R(8), R(10),
B(CallRuntime), U16(Runtime::kDefineClass), R(9), U8(3),
B(Star), R(9),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(CreateClosure), U8(13), U8(4), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(4),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
B(LdaConstant), U8(9),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(5),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
B(CreateClosure), U8(14), 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(8),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(CreateClosure), U8(15), 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(9),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Mov), R(4), R(6),
B(Mov), R(10), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(5),
B(Star), R(5),
B(CreateClosure), U8(16), U8(7), U8(2),
B(Star), R(6),
B(StaNamedProperty), R(4), U8(7), U8(2),
B(PopContext), R(3),
[scope] Add Scope::ForEach helper to avoid recursion Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
2019-01-31 15:36:58 +00:00
B(Mov), R(4), R(1),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
/* 140 E> */ B(CreateBlockContext), U8(17),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(PushContext), R(3),
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
B(LdaConstant), U8(2),
B(Star), R(5),
B(LdaConstant), U8(2),
B(Star), R(5),
B(CallRuntime), U16(Runtime::kCreatePrivateNameSymbol), R(5), U8(1),
Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" This reverts commit 392a1217dea6374314c496d09ccecfc7e9fc19fc. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d44243c20842dd0e48d50b00bafe18ff93 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1c48d7039b2b6eb758bca4588dc372654 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
2019-10-22 09:47:12 +00:00
B(StaCurrentContextSlot), U8(3),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
/* 356 E> */ B(CreateClosure), U8(19), U8(8), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(4),
[class] show private name in invalid private field access This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
2018-12-20 21:59:39 +00:00
B(LdaConstant), U8(18),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(5),
B(Mov), R(4), R(6),
B(Mov), R(1), R(7),
B(CallRuntime), U16(Runtime::kDefineClass), R(5), U8(3),
B(Star), R(5),
Allocate feedback cells in an array decoupled from other slots This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
2019-03-08 14:57:54 +00:00
B(CreateClosure), U8(20), U8(9), U8(2),
[class] implement static private methods This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
2019-10-10 14:33:02 +00:00
B(Star), R(6),
B(StaNamedProperty), R(4), U8(7), U8(4),
B(PopContext), R(3),
B(Mov), R(4), R(2),
/* 430 S> */ B(Ldar), R(0),
/* 430 E> */ B(Construct), R(0), R(0), U8(0), U8(6),
/* 439 S> */ B(Ldar), R(1),
/* 439 E> */ B(Construct), R(1), R(0), U8(0), U8(8),
/* 448 S> */ B(Ldar), R(2),
/* 448 E> */ B(Construct), R(2), R(0), U8(0), U8(10),
[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] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
/* 458 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: [
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_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
FIXED_ARRAY_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["#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
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SYMBOL_TYPE,
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_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
FIXED_ARRAY_TYPE,
[class] fix undefined private name access in computed property keys This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
2019-10-10 19:00:28 +00:00
ONE_BYTE_INTERNALIZED_STRING_TYPE ["#b"],
[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,
[class] Add bytecode expectations test for private class fields Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876 Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
2018-02-22 07:39:27 +00:00
SHARED_FUNCTION_INFO_TYPE,
[runtime] Add SCOPE_INFO_TYPE InstanceType Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51324}
2018-02-16 12:36:47 +00:00
SCOPE_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
FIXED_ARRAY_TYPE,
SHARED_FUNCTION_INFO_TYPE,
SHARED_FUNCTION_INFO_TYPE,
]
handlers: [
]
Reference in New Issue Copy Permalink