• Sathya Gunasekaran's avatar
    [class] Store class fields initializer on the constructor · 4ca9d843
    Sathya Gunasekaran authored
    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: 's avatarGeorg Neis <neis@chromium.org>
    Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#49628}
    4ca9d843
Name
Last commit
Last update
..
bytecode_expectations Loading commit data...
bytecode-expectations-printer.cc Loading commit data...
bytecode-expectations-printer.h Loading commit data...
generate-bytecode-expectations.cc Loading commit data...
interpreter-tester.cc Loading commit data...
interpreter-tester.h Loading commit data...
source-position-matcher.cc Loading commit data...
source-position-matcher.h Loading commit data...
test-bytecode-generator.cc Loading commit data...
test-interpreter-intrinsics.cc Loading commit data...
test-interpreter.cc Loading commit data...
test-source-positions.cc Loading commit data...