New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowed non-this, non-super code before super call in derived classes with property initializers #29374
Allowed non-this, non-super code before super call in derived classes with property initializers #29374
Conversation
Fixes microsoft#8277. 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`?
|
tests/baselines/reference/derivedClassSuperProperties.errors.txt
Outdated
Show resolved
Hide resolved
…boundaries ```ts function () { return this; } ``` It was immediately going to `ts.forEachChild` so the statement itself wasn't being counted as a new `this` scope.
This is getting very complex very fast. I wonder if there's an easier way using the control flow graph?
tests/baselines/reference/derivedClassSuperProperties.errors.txt
Outdated
Show resolved
Hide resolved
As per discussion in the issue, it would be ideal to consider any block that always ends up calling to super() the equivalent of a root-level super() statement. This would be valid: ```ts foo = 1; constructor() { condition() ? super(1) : super(0); this.foo; } ``` ...as it would compile to the equivalent of: ```ts function () { condition() ? super(1) : super(0); this.foo = 1; this.foo; } That change would a bit more intense and I'm very timid, so leaving it out of this PR. In the meantime the requirement is that the super() statement must itself be root-level.
cc @ahejlsberg for review |
Ping @ahejlsberg - is there anything that needs to be done here? It'd be nice to have this in |
Correction: ping, @weswigham? |
Heya @rbuckton, I've started to run the perf test suite on this PR at 39d9901. You can monitor the build here. Update: The results are in! |
@rbuckton Here they are:Comparison Report - main..29374
System
Hosts
Scenarios
Developer Information: |
@rbuckton Is there anything else that @JoshuaKGoldberg can do to move this forward? |
@typescript-bot user test this inline |
Nope, it looks ready to go actually, and just in time for 4.6 beta. |
Fantastic, thanks so much for the reviews & merge @rbuckton! If any issues come out of this change I'm available to try to fix, if that's helpful. |
The longest-living PR I have ever seen. |
YES!!! Thank you! |
|
Amazing work and perseverance. Awesome! |
Man! Awesome. The perseverance! |
Starts on #8277 by allowing the non-
this
, non-super
code to be root-level statements in the constructor. This will now be allowed:It feels wrong to put a newforEachChild
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 tosuper
orthis
?Edit 2/28/2020: I've
✔️
mostlyresolved the merge conflicts introduced by both#
private fields &useDefineForClassFields
, but I'm not confident my approach is still a valid one. I'd greatly appreciate it if someone could confirm I'm on the right track!Oh, andgulp runtests
passes locally (on Windows). I'll try a Mac to see if there's some odd encoding/whitespace behavior with the failing test...Edit 3/11/2021: It seems this is fairly close to merging.
Edit 1/13/2022: I bought this PR a birthday cake for its third birthday. https://twitter.com/JoshuaKGoldberg/status/1481654056422567944