-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
LibJS: RAII in js???? #16630
LibJS: RAII in js???? #16630
Conversation
as much as I like the code and effort, i guess that dealing with stage 2 might not be a best idea. (there was e.g. a split with stage 2 implementation of decorators being implemented once…). iʼm not really against it but i would advise to wait for at least stage 3 proposal. |
This proposal is already at stage 3, although it's not mentioned in the repo itself, but it is listed here: https://github.com/tc39/proposals under stage 3 and babel/proposals#85 (comment) this is where I got the fact that async is not stage 3. I think some stuff will still change (I even found some spec issues) but I'm up for updating the code as the proposal gets updated. |
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.
The bytecode impl is gonna be hell isn't it...
Just some random comments, nothing groundbreaking here:
|
||
test("using using of", () => { | ||
let enteredLoop = false; | ||
for (using using of [null]) { |
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.
...wtf
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |
9ff1c2b
to
342a4d8
Compare
342a4d8
to
fde185f
Compare
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.
Great stuff! Once again we have better test coverage than test262 😄
Userland/Libraries/LibJS/Runtime/SuppressedErrorConstructor.cpp
Outdated
Show resolved
Hide resolved
Userland/Libraries/LibJS/Runtime/SuppressedErrorConstructor.cpp
Outdated
Show resolved
Hide resolved
Userland/Libraries/LibJS/Runtime/DisposableStackConstructor.cpp
Outdated
Show resolved
Hide resolved
fde185f
to
ecedcd4
Compare
Addressed most of the comments, just not sure what would be best in the Optional reference case |
ecedcd4
to
f647d87
Compare
Userland/Libraries/LibJS/Runtime/DisposableStackConstructor.cpp
Outdated
Show resolved
Hide resolved
Without a message these just show 'ExpectationError' even if the check has multiple steps.
Any test with multiple expect(...).toBe{True, False} checks is very hard to debug.
This will allow us to specify things like SyncDispose and perhaps AsyncDispose in the future.
In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
The using declarations have kind of special behavior in for loops so this is seperated.
Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack.
f647d87
to
04b432a
Compare
Done and also quickly checked all the commit do build and run |
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.
Thanks for the initial implementation, great work! 🎉
Still need to make some issues in the repo about spec problems, also the spec is only partly accepted so no async parts.