-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Proposal class static block support #43370
Proposal class static block support #43370
Conversation
* Add types factory and parser * Add some case * Make class static block as a container * Update cases * Add visitor * Add emitter and more compile target * Check boundary of break and continue
Let's try it again. @orta @typescript-bot pack this. |
Hey @Kingwl, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
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.
I know this is still a Draft, but thought you might appreciate some early feedback.
We should have logic in the checker to check for invalid decorators or modifiers. We also should be checking for invalid uses of await
as an identifier in the block.
One of problem is we do not have something like If I'm correct. We should check many thinks:
Seems it's very expensive? I would like to add a (flag? property?) into identifier if it's parsed by And we need many cases to check about the function boundary. |
We could handle this via a special parser context, similar to For example, we don't allow interface await {} // ok
async function f() {
interface await {} // error, because we're in an Await context
const a: await = 1; // not an error because parsing a type annotation exits the Await context
} |
Also |
This shouldn't be necessary. |
Should we also deny the await identifiers inside type context? |
Basically checked the function boundary. Computed property name is a known issue. |
If it helps, I can work on the missing language service features and tests for |
Appreciate, if it need to be done before today end. |
I'd like to get this in before noon PDT on Friday. I've pushed up support for call hierarchy, references, and go to definition along with relevant tests. |
From a conversation with @RyanCavanaugh, it seems like we want to try to wrap 4.4 features today. I will do what I can to get this PR merged by EOD. |
I'm not sure what time zone that you say but I'll stay late this night (6/25, your morning). |
I think this is good to merge except for the missing |
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.
I think this looks good. We can address this
support in static {}
in #43114.
@typescript-bot perf test |
Heya @rbuckton, I've started to run the perf test suite on this PR at 6234640. You can monitor the build here. Update: The results are in! |
After the bot checks all the things, I can merge this in the morning if there are no major breaks. Then we can work on getting this to work with #43114. |
@rbuckton Here they are:Comparison Report - main..43370
System
Hosts
Scenarios
Developer Information: |
Some tests failed. But seems not my fault. |
@typescript-bot pack this. |
Hey @Kingwl, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
Closes #43308
Fixes #43012