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`?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
tests/baselines/reference/derivedClassSuperProperties.errors.txt Outdated Show resolved Hide resolved
Uh oh!
There was an error while loading. Please reload this page.
…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?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
tests/baselines/reference/derivedClassSuperProperties.errors.txt Outdated Show resolved Hide resolved
Uh oh!
There was an error while loading. Please reload this page.
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.
Uh oh!
There was an error while loading. Please reload this page.
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? |
@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. |
…rosoft/TypeScript#29374 The minimum TypeScript dependency is lifted to 4.6.2
Guy you've made it reddit programmer humor front page! https://www.reddit.com/r/ProgrammerHumor/comments/waa0lz/if_youre_ever_frustrated_that_your__prs/ |
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