Support named evaluation for decorated anonymous class exp

[JLHwung]

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

This PR supersedes #15122.

The only change compared with #15122 is that we now apply toPropertyKey when memoising the computed key passed to the setFunctionName helper call. So that we can now handle the following edge case as well

function dec (target, context) {
  // should print "2.71828", "2.71828"
  console.log(target.name, context.name)
}
new class C {
  [{ [Symbol.toPrimitive]: () => Symbol(2.71828) }] = @dec class { p; };
}

The implementation is not changed very much. I tried to reorganize the changes so the it might be easier to review by commits.

In #15122 we discussed whether we should merge the NamedEvaluationVisitoryFactory with our current function name utilities. To recap, we introduced a setFunctionName runtime helper in #16144, at this point we have two helpers that can name a function:

• babel-helper-function-name (A): an AST transform that wraps a given function with a new function whose id is the desired name, and preserved the source of the given function
  • Pros: Works for ES3, even in old browsers where redefining the name property might throw
  • Cons: Does not support naming class. Does not support arbitrary name, e.g. it can't name the function as "output the best number between 2 and 3" because that is not a valid identifier. Bigger output than approach B
• babel-runtime/setFunctionName (B): a runtime call to set the name property of the given function
  • Pros: Works for both classes and functions, supports any name, smaller output than approach A when runtime is externalized
  • Cons: Does not work in old browsers where redefining the name property might throw

They are used by two transforms: The approach A is used by function-name transform and the approach B is used by the decorators transform in this PR as well as the decorator runtime.

I think we can consider merge NamedEvaluationVisitoryFactory with the function-name transform. The factory generates a visitor that will take care of various AST subjects to the named evaluation, and the function-name transform can decide whether it should use approach A or approach B for the related AST nodes. We can also come up with a compat table so that the function-name transform can emit the SetFunctionName call when the browser supports it, and fallback to the heavier helper-function-name AST transform.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/55954/

[JLHwung]

This is a bug fix. The input is

"use strict";
class Hello {
  toString() {
    return 'hello';
  }
}

class Outer extends Hello {
  constructor() {
    super();
    class Inner {
      accessor [super.toString()] = 'hello';
    }

    return new Inner();
  }
}

expect(new Outer().hello).toBe('hello');

As we can see from the output, the super.toString() is executed twice when we transform the accessor to get-set pairs since we forgot to memoize the computed key.

[JLHwung]

The test is more hardened than #15122, here we further assert value.name should equal context.name.

[JLHwung]

In this case, we don't have any decorators, but we should still transform the class accessors, the assignments at this time must be the memoized accessor keys.

[nicolo-ribaudo]

Can you add this as an in-code comment? :)

[liuxingbaoyu]

Is this expected?

[JLHwung]

Yes, the input is

const dec = () => {}; 
class Foo {
  accessor a;

  accessor b = 123;

  accessor ['c'] = 456;
}

And 'c' should not be computed twice. Though in this case there is no behaviour changes if 'c' is used in both getter and setter keys.

[liuxingbaoyu]

https://github.com/babel/babel/pull/16148/files#diff-ec0a7c89e1c00ced2b4a8ccee78aa564e798866f0815a815ff14c99bb49bb821R600
I just noticed that we have static nodes as a special case, literals appear to be static as well. :)

[liuxingbaoyu]

Thanks!

[nicolo-ribaudo]

Note that in general we don't preserve correct function names, but we only try to give some useful names for debugging purposes in stack traces. For example, we compile

0, {
  "ab method"() {}
}

to

0,
  {
    "ab method": function abMethod() {}
  };

However, I think this PR is fine because the class name is explicitly exposed to decorators through context.name, and not just "accidentallyviaFunction.prototype.name`.

[nicolo-ribaudo]

Can you add this as an in-code comment? :)