-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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? |
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! 🎉 |
Does it mean that now super is going to be invoked the first time never mind where he is located in the constructor? |
…rosoft/TypeScript#29374 The minimum TypeScript dependency is lifted to 4.6.2
Congrats, apparently the cake did it's job! 🎉 |
Guy you've made it reddit programmer humor front page! https://www.reddit.com/r/ProgrammerHumor/comments/waa0lz/if_youre_ever_frustrated_that_your_github_prs/ |
grats on the PR |
Congrats !! Happy for you! |
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, and✔️gulp 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