Allowed non-this, non-super code before super call in derived classes with property initializers

[JoshuaKGoldberg]

Starts on #8277 by allowing the non-this, non-super code to be root-level statements in the constructor. This will now be allowed:

class Base { }
class Derived extends Base {
    public prop = true;
    constructor(public paramProp = true) {
        console.log("Hello, world!");
        super();
    }
}

It feels wrong to put a new forEachChild loop in the checker, though in the vast majority of user files this will be a very quick one. Is there a better way to check for a reference to super or this?

[weswigham]

It feels wrong to put a new forEachChild loop in the checker, though in the vast majority of user files this will be a very quick one. Is there a better way to check for a reference to super or this?

TransformFlags.Super | TransformFlags.ContainsSuper for super at least.

[ajafff]

This is getting very complex very fast. I wonder if there's an easier way using the control flow graph?

[RyanCavanaugh]

cc @ahejlsberg for review

[JoshuaKGoldberg]

Ping @ahejlsberg - is there anything that needs to be done here? It'd be nice to have this in 😄

[JoshuaKGoldberg]

Correction: ping, @weswigham?

[JoshuaKGoldberg]

Well this is fun: private named instance fields (#30829) did some merge conflict damage here 😅. I'll merge from master best I can now with a gulp baseline-accept to get this cleaned up, attempt to get the tests reasonable, and start pinging folks in earnest this week.

[JoshuaKGoldberg]

Note that this is a behavioral change for when H is used incorrectly as a callable function:

let invalid = H();

...but the new output is a correction, as when H is changed to extend Object, the return does exist.

[JoshuaKGoldberg]

😡. Introduced issue thanks to merge conflicts. Will fix...