-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add proposal-promise-any #6641
Add proposal-promise-any #6641
Conversation
Thanks for carrying on with this. FYI on test fails:
|
Yep. It will fail without flags. And I haven't find out why.
Okay, Thanks. There's already existed test262. Should we add more test about that? |
If you're on windows it needs to be run in a developer command prompt as it calls MsBuild; on macOS/Linux I can't think of it reason for it to fail. When run fully it generates 4 files - covering each combination of: x64 or x86 with Jit OR no Jit. Your PR currently has updates for x64 Jit and x86 jit but doesn't have the versions for noJit.
I was commenting on the existing test cases that are failing (because they're checking properties of the GlobalObject and not expecting to find AggregateError) we'll need new test cases as well BUT I was wrong - much easier fix don't need to update all the tests - just add AggregateError to this list to take it out of these tests: ChakraCore/bin/ch/DbgController.js Lines 63 to 128 in 11d9375
|
Yeah. I know about that. I mean: I saw we have 262test. And should I add some case even they has overlapping with test262. |
We do need specific tests; test262 is not run on check in - the test262 folder just tests part of the harness. |
Okay. I think I'd better copy some tests from test262. |
Sorry I'm not sure what TTD is. And what should I do for TTD. Would you mind give some suggestion? thanks! |
TTD = "Time Travel Debug" it is support for running javascript backwards for debugging purposes - it's a unique feature of Chakracore - sadly I'm not sure if anyone uses it at the moment BUT I'd like to keep it working if we can. TTD Snap methods save the current JS state out to a file, Inflate methods take information from the file to recreate a specific JS state. So you'll probably need Snap/Inflate support for AggregateError. Perhaps look at how Snap/Inflate work for something containing a list of Promises. |
Seems the spec has some changes between this and the previous PR. According the latest spec. We needn't extends JavascriptError anymore. I'll update these soon. |
That sounds strange to me, I thought one of the key purposes of AggregateError (instead of an Array of Errors) was so it would test true as |
Nope. That's not related about runtime behavior. It's talk about the implementations in this PR -> |
If there's no detectable runtime difference the implementation doesn't matter - spec details about implementation are only authoritative if runtime can detect them. That said - I'd need to check the details but I imagine having it internally extend JavascriptError makes sense for a lot of reasons - is there a disadvantage you're aware of? Or an observable instance of incorrect runtime behaviour? |
One reason is that all the previous Errors directly reference to JavascriptError. And the property |
BTW: Should this behind a flag? |
This proposal is stage 4, no need in a flag. |
Sometimes it's good to have a flag even for a stage 4 proposal/feature - if it introduces a bug or a strange issue can be helpful for debugging to turn it off OR if the bug is too serious to be able to disable the feature and a ship a version without it - hopefully unnecessary but useful to have there with any particularly invasive features. |
+1. I'd suggest keeping any non-trivial feature behind a flag, at least until it's been successfully released. Even then, there can be surprising compat impact out in the world, and it's nice to be able to flip the switch to off while you investigate. |
I think this one is basically done. But there's something I'm not sure:
|
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've not finished - but I've raised several points that need addressing above - found some spec deviations and a few segfaults/hard crashes as well as some less important style points.
PTAL. Major issues has been resolved (I think). |
I'm sorry I merged another PR with a bytecode regen - you will need to fix the merge conflict and then re-run the bytecode regen script. |
PTAL. |
Thanks for the further updates, I'll aim to pull this down and re-review tomorrow, sorry for the delay - not a small diff. |
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.
Mostly looking good now - one serious bug which needs fixing + a test adding.
And it would be good if the AggregateError tests could be a bit nicer (similar format and clarity etc. to the other test files)
test/Error/aggregate_error.js
Outdated
var case9 = { | ||
[Symbol.iterator]() { | ||
return { | ||
next() { | ||
return undefined; | ||
} | ||
} | ||
} | ||
}; | ||
assert.throws(() => { | ||
var obj = new AggregateError(case9); | ||
}, TypeError); |
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 next few tests appear to be about iterators that don't provide objects -would be good to specify that.
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.
Sorry I'm not sure what‘s the point.
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.
Basically that I'd like it to be clearer when re-reading the test file what it's doing/what these cases are for.
It appears from reading them that they're testing behaviour when an iterator doesn't provide an object - but there's no comment description saying that that is what they're doing/why they're here.
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 response. I have tried to add some comments above the case. Does they seems enough?
Thanks for the review. I would like to take a look in few days. |
Thanks for all your work on this @Kingwl |
Thanks for your review! |
Closes #6301
FIxes #6299