Reduce element decorator temp variables

[JLHwung]

Q	A
Fixed Issues?	Implements #16218 (comment)
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This PR is inspired from #16218.

Previously Babel memoises each individual decorator expressions, combines them into an array and passes it to the applyDecs helper. In this PR we memoise the combined decorators + decoratorThis array, so we allocate atmost 1 temporary variable for each decorated class fields.

Code Example

Input

function decFactory() {
  return () => {}
}

class C {
  @decFactory(1)
  @decFactory(2)
  foo() {}
  
  @decFactory(3)
  @decFactory(4)
  bar() {}
}

Output on main

var _initProto, _dec, _dec2, _dec3, _dec4
function decFactory() {
  return () => {};
}
_dec = decFactory(1);
_dec2 = decFactory(2);
_dec3 = decFactory(3);
_dec4 = decFactory(4);
class C {
  static {
    [_initProto] = _applyDecs(this, [[[_dec, _dec2], 2, "foo"], [[_dec3, _dec4], 2, "bar"]], []).e;
  }
  constructor() {
    _initProto(this);
  }
  foo() {}
  bar() {}
}

Output on this PR

var _initProto, _fooDecs, _barDecs;
function decFactory() {
  return () => {};
}
_fooDecs = [decFactory(1), decFactory(2)];
_barDecs = [decFactory(3), decFactory(4)];
class C {
  static {
    [_initProto] = babelHelpers.applyDecs2311(this, [[_fooDecs, 2, "foo"], [_barDecs, 2, "bar"]], []).e;
  }
  constructor() {
    _initProto(this);
  }
  foo() {}
  bar() {}
}

While the example above shows the output of 2023-11 decorator versions, this optimization is available for other decorator versions later than 2021-12 as well.

Note that this PR does not seek to memoise all element decorator expressions into one memoiser, since computed keys have to be interleaved with decorator evaluations.

This PR contains commits from #16279. It also contains small memory tweaks.

[liuxingbaoyu]

Due to #16218 (comment) , I suspect this will need to wait until tc39/proposal-decorators#524 is implemented.

[JLHwung]

I think this PR is not depending on tc39/proposal-decorators#524, since any normative change of decorator application ordering should be implemented within toSortedDecoratorInfo.

[liuxingbaoyu]

I just saw the latest PR description and thought it was good.

[JLHwung]

Nit: we should unify haveThis and hasThis.

[nicolo-ribaudo]

Maybe I'm missing something onvious, byt why do we need the temporary variable at all? This code behaves identically to

_classDecs = [void 0, dec, void 0, call(), void 0, chain.expr(), void 0, arbitrary + expr, _obj, _obj[expr]];
_obj2 = array;
class Foo {
  static {
    ({
      e: [_initProto],
      c: [_Foo, _initClass]
    } = babelHelpers.applyDecs2311(this, [[[void 0, dec, void 0, call(), void 0, chain.expr(), void 0, arbitrary + expr, _obj2, _obj2[expr]], 18, "method"]], _classDecs, 1));

[JLHwung]

why do we need the temporary variable at all?

Because computed keys have to be interleaved with decorator evaluations and the static block is evaluated after a method with computed key is defined.

If there aren't computed keys, we could move element decorators into the static block with the following caveat:

• If there is super() within the decorator, we should capture and replace the super call first before moving to the static block. There is even a test packages/babel-plugin-transform-class-properties/test/fixtures/nested-class/super-call-in-decorator/exec.js

[nicolo-ribaudo]

Oh I see. Let's merge this as-is for now, I'll experiment to see how much complex supporting it would be.

[liuxingbaoyu]

FYI: The current proposal has a discussion about order, which would be much simpler if the changes were accepted.
tc39/proposal-decorators#524
Also I have an idea about a bindDecs helper.
Similar to the behavior of ts, call fn.bind(obj) directly or use a closure to save it. This way we can simplify the logic and reduce some void 0.

[JLHwung]

If there are computed keys, eventually the element decorator evaluations should be pushed to the computed key to ensure that they have proper private element (The last opening ticket in #16117).

When the class is decorated, the situation become more complicated because some keys are moved further inside to the non-statics class. The inside class has more complete private environment access but it is defined later than the other method elements in the outside statics class. We may have to capture private access (even potentially reuse those passed to the applyDecs) as well.