Reduce helper size for decorator 2023-11

[liuxingbaoyu]

Q	A
Fixed Issues?	Fixes #1, Fixes #2
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

1. Removed multiple decorated checks for method/accessor with the same name. (This check is large and only used in extreme exception scenarios, the new behavior is consistent with ts)
2. Removed the try/catch in the helper, now the decorator completion check will only be performed if there is no throw.
3. Removed some function parameters in helpers, which can directly access variables in the parent scope.

[liuxingbaoyu]

I'm not sure if this is useful, there are no tests related to it.

[nicolo-ribaudo]

Yeah decInfo is always an array. It's probably a leftover from an old version.

[nicolo-ribaudo]

We might at some point consider passing this as a parameter to applyDecs2023 (with the || Symbol.for("Symbol.metadata") fallback inside the helper), so that it can be polyfilled when using core-js-pure. Similarly to how we pass Promise when compiling async functions.

[liuxingbaoyu]

It seems to have been polyfilled now?

[nicolo-ribaudo]

Oh yeah, right :) I was thinking about the case with polyfill + @babel/runtime, but now all our polyfill injection methods will use the already polyfilled runtime package.

[nicolo-ribaudo]

It might be observable in this test case (I'm not sure):

let addInitializer;
function foo(ctx) {
  addInitializer = ctx.addInitializer;
  throw {};
}
try {
  class A { @dec foo = 2; }
} catch {}

expect(() => addInitializer(() => {})).toThrow();

[liuxingbaoyu]

Yes, this can be observed.
But when the decorator throws an error, it seems that this check is no longer important.
What do you think?

[nicolo-ribaudo]

Well, we should make sure to match the spec :)

https://ci.tc39.es/preview/tc39/ecma262/sha/59003ed603d09485b957a0f579b46697f49a96a6/#sec-applydecoratorstoelementdefinition

It looks like if calling the decorator throws then decoratorFinishedRef is not set to true, because the ? in step of 5.j is an early return in case of error. So removing the try/catch is indeed correct.

However, we should move the decoratorFinishedRef.v assignment to right after the newValue = dec.call( call, so that if one of the following validation steps throws then we still have it set to true.

Then, please add a test for when the decorator throws (addInitializer should still be callable) and for when one of the subsequent checks throws (addInitializer should not be callable anymore) :)

[nicolo-ribaudo]

We don't need to .bind here, we can just capture it from the outer scope right? Since decoratorFinishedRef. And then we could even just replace decoratorFinishedRef with a plain boolean.

[liuxingbaoyu]

This produces another observable change.
The addInitializer saved by the user in @dec1 can be used in @dec2, which is the current behavior of ts.
I'm fine with both behaviors.

[nicolo-ribaudo]

Oh right, than let's keep the current behavior. decorationState is per-decorator in https://ci.tc39.es/preview/tc39/ecma262/sha/59003ed603d09485b957a0f579b46697f49a96a6/#sec-applydecoratorstoelementdefinition, so the addInitializer should not be valid accross multiple decs.

[nicolo-ribaudo]

I opened microsoft/TypeScript#57300 for TS.

[nicolo-ribaudo]

What happens now when we decorate a public method/accessor with the same name of one that has been already decorated?

[liuxingbaoyu]

I thought there would be a seemingly incorrect ctx like #16263 (comment),
At the same time, the decorator's operation on the first property may be reflected on the second property? Because the second property overrides the first property. I'm not sure, just guessing. :)

[JLHwung]

I think we should still keep this check, which informs users that we don't support such cases, even though they are allowed in the spec.

Another example is

function dec(value) {
  console.log(value.constructor.name)
}


class Foo {
  @dec a() {};
  @dec async a() {};
}

It should log Function and AsyncFunction. Currently we will throw that error, otherwise it will log AsyncFunction twice (in this PR), which is incorrect. In practise such code is likely a developer error, like copying a method twice, we are throwing for good reasons.

[liuxingbaoyu]

Unfortunately this check accounts for 10% of the helper's size. (also after gzip)

[nicolo-ribaudo]

Is it correct that this returns 2 and not 1?

[liuxingbaoyu]

It seems so. I'm not sure if the spec supports such usage. ts behaves the same as after this PR.
The size of this check is ~10% of the helper's. 🤔

[nicolo-ribaudo]

@pzuraq Do you have a couple examples of what is the expected behavior when decorating class fields & methods that have the same name?

• two prototype methods
• static method and prototype method
• instance field and prototype method
• two instance fields

[pzuraq]

Decorators apply to each individual element independently, and then the element is applied to the class definition in the same order and with the same timing and semantics as if they were not decorated. So:

two prototype methods

1. Decorators are applied to the first method
2. First method is assigned to the class prototype
3. Decorators are applied to the second method
4. Second method is assigned to the class prototype, overwriting the first method

static method and prototype method

1. Decorators are applied to the static method
2. Static method is assigned to the class
3. Decorators are applied to the prototype method
4. Prototype method is assigned to the class prototype

instance field and prototype method

1. Decorators are applied to the prototype method
2. Prototype method is assigned to the class prototype
3. Decorators are applied to the instance field
4. On initialization, the instance field is [Define]d on the instance, shadowing the prototype method

two instance fields

1. Decorators are applied to instance field 1
2. Decorators are applied to instavce field 2
3. Instance field 1 is initialized and defined on the instance
4. Instance field 2 is initialized and defined on the instance, overwriting instance field 1

In every case, the decoration phase is not altered at all by the existence of another element with the same name. There is no side-channeled information, etc.

When they are the same static, the only case that doesn't end up with the element being overwritten/shadowed is getter and setter with the same name, which will coalesce into a normal getter setter pair.

[nicolo-ribaudo]

Thank you!

@liuxingbaoyu At least for the "two methods" case we are not implementing the proposal properly -- let's keep the error, but we can shorten the message for example to "Decorating two elements with the same name (" + name + ") is not supported yet"

[liuxingbaoyu]

I don't love the size of this, but I'll keep it in this PR.
I refactored this check, but it still accounts for ~7% of the entire helper, also after gzip.
But luckily we reduced some other sizes inspired by #16261.

[nicolo-ribaudo]

Yeah decInfo is always an array. It's probably a leftover from an old version.

[nicolo-ribaudo]

Suggested change

	: runInitializers.call.bind(desc[key]),
	: Function.call.bind(desc[key]),

Here it doesn't actually matter that we are using runInitializers, because we are replacing .call's function with desc[key] anyway. Let's just use Function.call.bind to avoid potential confusion.

[liuxingbaoyu]

This will add some extra size, can we add some comments instead? :)

[nicolo-ribaudo]

Sure!

[JLHwung]

Can you leave a comment here that _ is an accumulator, which will be frequently reassigned and serve only as a temporary variable.

[JLHwung]

I think we should still keep this check, which informs users that we don't support such cases, even though they are allowed in the spec.

Another example is

function dec(value) {
  console.log(value.constructor.name)
}


class Foo {
  @dec a() {};
  @dec async a() {};
}

It should log Function and AsyncFunction. Currently we will throw that error, otherwise it will log AsyncFunction twice (in this PR), which is incorrect. In practise such code is likely a developer error, like copying a method twice, we are throwing for good reasons.

[nicolo-ribaudo]

Could you add this test?

class {
  @dec method() {}
  @dec set method(_) {}
}

[liuxingbaoyu]

Thanks!