[go: nahoru, domu]

Skip to content
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

Merged
merged 61 commits into from
Jan 14, 2022

Conversation

JoshuaKGoldberg
Copy link
Contributor
@JoshuaKGoldberg JoshuaKGoldberg commented Jan 11, 2019

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?

Edit 2/28/2020: I've mostly resolved 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

Blue and white cake with text 'Happy 3rd birthday, #29374 Bump for PR review please!' and the TypeScript logo. A tall slice is removed.

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`?
src/compiler/checker.ts Outdated Show resolved Hide resolved
src/compiler/utilities.ts Outdated Show resolved Hide resolved
src/compiler/utilities.ts Outdated Show resolved Hide resolved
@weswigham
Copy link
Member

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.

src/compiler/utilities.ts 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.
Copy link
Contributor
@ajafff ajafff left a 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?

src/compiler/utilities.ts Outdated Show resolved Hide resolved
src/compiler/checker.ts Outdated Show resolved Hide resolved
src/compiler/utilities.ts Outdated Show resolved Hide resolved
src/compiler/utilities.ts Outdated Show resolved Hide resolved
src/compiler/utilities.ts Outdated Show resolved Hide resolved
Josh Goldberg added 3 commits January 15, 2019 14:40
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.
src/compiler/utilities.ts Outdated Show resolved Hide resolved
@RyanCavanaugh
Copy link
Member

cc @ahejlsberg for review

@JoshuaKGoldberg
Copy link
Contributor Author

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

@RyanCavanaugh RyanCavanaugh added this to the TypeScript 3.6.0 milestone Jul 12, 2019
@JoshuaKGoldberg
Copy link
Contributor Author

Correction: ping, @weswigham?

@typescript-bot
Copy link
Collaborator

Heya @rbuckton, I'm starting to run the inline community code test suite on this PR at 1b3dd6d. Hold tight - I'll update this comment with the log link once the build has been queued.

@rbuckton
Copy link
Member

@rbuckton Is there anything else that @JoshuaKGoldberg can do to move this forward?

Nope, it looks ready to go actually, and just in time for 4.6 beta.

PR Backlog automation moved this from Waiting on author to Needs merge Jan 14, 2022
@rbuckton rbuckton merged commit b7fee7f into microsoft:main Jan 14, 2022
PR Backlog automation moved this from Needs merge to Done Jan 14, 2022
@JoshuaKGoldberg JoshuaKGoldberg deleted the non-this-super-before-super branch January 14, 2022 14:31
@JoshuaKGoldberg
Copy link
Contributor Author

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.

@NaveedAhmadHematmal
Copy link

The longest-living PR I have ever seen. 😳

@lukescott
Copy link
lukescott commented Jan 20, 2022

YES!!! Thank you!🎉 🎉 🎉

@callumok2004
Copy link

🥳🎉🎉

@iJungleboy
Copy link

Amazing work and perseverance. Awesome!

@EstopaceMA
Copy link

Man! Awesome. The perseverance! 🎉

@vladboss61
Copy link

Does it mean that now super is going to be invoked the first time never mind where he is located in the constructor?

eemeli added a commit to messageformat/messageformat that referenced this pull request Jul 16, 2022
@jfortier-haptiq
Copy link

Congrats, apparently the cake did it's job! 🎉

@gbersac
Copy link
gbersac commented Jul 28, 2022

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/

@taylus
Copy link
taylus commented Jul 28, 2022

grats on the PR

@upq
Copy link
upq commented Jul 28, 2022

Congrats !! Happy for you!
Might as well be the most famous PR yet ... from branding perspective I recommend you naming the PR
Suggestion: Des Supa

@microsoft microsoft locked as resolved and limited conversation to collaborators Jul 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
Archived in project
PR Backlog
  
Done
Development

Successfully merging this pull request may close these issues.

None yet