Baseline changes for ESNext Class Property Transformation

[joeywatts]

The transformation of class fields has been moved to the ESNext transformation on this branch.

This PR is for discussion on the baseline changes (so it doesn't crowd the logic of the PR).

[mheiber]

10:34:31 What we're looking for is making sure that the semantics don't change, with the exception of (I think) one intentional change: that when there is a field def, the property is added to the object (with value undefined if value isn't set)

(@joeywatts found this TS issue for passing through properties in this manner: microsoft#12212)

[mheiber]

note on how to review this:

The TS test cases work as follows:

• Test inputs (called "cases") typically end in .ts. They are not included in this PR (since the inputs didn't change). Example: tests/cases/compiler/decoratorsOnComputedProperties.ts
• Test case expected output (called "baselines") are all in tests/baselines/reference

So I'd recommend reviewing this by cloning the TS repo. Then, for each .js in the diff, go to the .ts file with the same name. See if the new baseline output has either:

• the same semantics as the original
• different semantics but in a way that is desirable

This is really difficult!

[mheiber]

why did this baseline change?

[joeywatts]

The TypeScript transformer handles the experimental decorator transformation. This made pulling out the property transformation from the TypeScript transformer difficult because there are computed property names that have to be used in both the original property declaration/assignment and in the call to the decorator helper function (and non-trivial computed property name expressions shouldn't be executed more than once).

I reconciled this by transforming the computed property names (not the actual property declaration/initializer) in the TypeScript transformer when they need to be used more than once by code generated by the TypeScript transformer.

The _a, _b, _c, _d variables are now hoisted in the ESnext transformer (they are class aliases which are emitted when a static property initializer references the name of its own class).
The other hoisted variables store computed property names for the decorated properties (created by the TypeScript transformer).

[mheiber]

intentional semantic change here

[mheiber]

where are the source files for the transformApi tests?

[joeywatts]

They just live in this one file: src/testRunner/unittests/transform.ts

[mheiber]

approving,

[mheiber]

why did the space in the source file go away?

class C {
    static readonly readonlyStaticCall = Symbol();
    static readonly readonlyStaticType: unique symbol;
    static readonly readonlyStaticTypeAndCall: unique symbol = Symbol();
    static readwriteStaticCall = Symbol();

    readonly readonlyCall = Symbol();
    readwriteCall = Symbol();
}

[joeywatts]

It looks like the emit never preserves the whitespace of the source file (from looking at the previous baseline and playing around with the TS playground)

[mheiber]

nice