Implement Promise.allSettled
https://github.com/tc39/proposal-promise-allSettled/ Shipping in Firefox since version 68. Shipping in V8 since https://chromium.googlesource.com/v8/v8.git/+/1f6d27e8df819b448712dface6ad367fb8de426b
<rdar://problem/50483885>
<rdar://problem/50483886>
Created attachment 369095 [details] WIP
Comment on attachment 369095 [details] WIP Attachment 369095 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12107506 New failing tests: http/tests/css/filters-on-iframes.html
Created attachment 369096 [details] Archive of layout-test-results from ews210 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews210 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Created attachment 369149 [details] WIP 2
Comment on attachment 369149 [details] WIP 2 View in context: https://bugs.webkit.org/attachment.cgi?id=369149&action=review > Source/JavaScriptCore/builtins/PromiseConstructor.js:87 > + return @Promise.all.@call(this, @Array.from(iterable, function (item) { I don't think this is correct. You can't use properties of the private globals unless the spec says to do so since they can be changed by the client and thus can be observed and/or changed.
Comment on attachment 369149 [details] WIP 2 Attachment 369149 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12114097 New failing tests: legacy-animation-engine/compositing/reflections/load-video-in-reflection.html
Created attachment 369161 [details] Archive of layout-test-results from ews214 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews214 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
*** Bug 196332 has been marked as a duplicate of this bug. ***
Comment on attachment 369149 [details] WIP 2 View in context: https://bugs.webkit.org/attachment.cgi?id=369149&action=review Some early comment. > Source/JavaScriptCore/builtins/PromiseConstructor.js:88 > + var promiseCapability = @newPromiseCapability(outerThis); You can just use arrow function if necessary. But seems that the spec requires manual iteration. So I think we should do here.
(In reply to Ross Kirsling from comment #11) > *** Bug 196332 has been marked as a duplicate of this bug. *** Slightly off-topic, but why is it that whenever I file a WebKit bug, it ultimately gets closed as a duplicate of another bug that was filed *after* my initial report? This happened more than a few times already. Should I just give up?
(In reply to Mathias Bynens from comment #13) > (In reply to Ross Kirsling from comment #11) > > *** Bug 196332 has been marked as a duplicate of this bug. *** > > Slightly off-topic, but why is it that whenever I file a WebKit bug, it > ultimately gets closed as a duplicate of another bug that was filed *after* > my initial report? This happened more than a few times already. Should I > just give up? No, you should not give up. We're not super picky about marking the first filed bug as the "original" bug. We usually just pick whichever bug is most convenient.
(In reply to Saam Barati from comment #14) > (In reply to Mathias Bynens from comment #13) > > (In reply to Ross Kirsling from comment #11) > > > *** Bug 196332 has been marked as a duplicate of this bug. *** > > > > Slightly off-topic, but why is it that whenever I file a WebKit bug, it > > ultimately gets closed as a duplicate of another bug that was filed *after* > > my initial report? This happened more than a few times already. Should I > > just give up? > > No, you should not give up. > > We're not super picky about marking the first filed bug as the "original" > bug. We usually just pick whichever bug is most convenient. I personally just use whichever bug I see first. I also sometimes forget to associate the bug with my patch so I end up creating a new bug and duping the old one.
Sorry Matthias. This was my fault. I didn't search for bugs before filing.
Created attachment 370789 [details] Patch
Comment on attachment 370789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370789&action=review r=me. > Source/JavaScriptCore/builtins/PromiseConstructor.js:150 > + promiseCapability.@resolve.@call(@undefined, values); Why does this need to be passed undefined as the this value? Isn't @resolve an internal method? Seems like the this value shouldn't matter. > Source/JavaScriptCore/builtins/PromiseConstructor.js:152 > + promiseCapability.@reject.@call(@undefined, error); Ditto. > JSTests/test262/expectations.yaml:1789 > +test/intl402/Collator/ignore-invalid-unicode-ext-values.js: > + default: 'Test262Error: Locale en is affected by key co; value standard. Expected SameValue(ëenû, ëen-AUû) to be true' > + strict mode: 'Test262Error: Locale en is affected by key co; value standard. Expected SameValue(ëenû, ëen-AUû) to be true' What? Does this test use promise.allSettled? Was this already failing? > JSTests/test262/expectations.yaml:1819 > +test/intl402/fallback-locales-are-supported.js: > + default: "Test262Error: Locale zh-Hans-CN is supported, but fallback zh-Hans isn't. Expected SameValue(ë-1û, ë-1û) to be false (Testing with Collator.)" > + strict mode: "Test262Error: Locale zh-Hans-CN is supported, but fallback zh-Hans isn't. Expected SameValue(ë-1û, ë-1û) to be false (Testing with Collator.)" Ditto...
Comment on attachment 370789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370789&action=review >> Source/JavaScriptCore/builtins/PromiseConstructor.js:150 >> + promiseCapability.@resolve.@call(@undefined, values); > > Why does this need to be passed undefined as the this value? Isn't @resolve an internal method? Seems like the this value shouldn't matter. From https://tc39.github.io/proposal-promise-allSettled/ 14. If remainingElementsCount.[[Value]] is 0, then 14.a Let valuesArray be ! CreateArrayFromList(values). 14.b Return ? Call(promiseCapability.[[Resolve]], undefined, « valuesArray »). I don't understand why :) >> JSTests/test262/expectations.yaml:1789 >> + strict mode: 'Test262Error: Locale en is affected by key co; value standard. Expected SameValue(ëenû, ëen-AUû) to be true' > > What? Does this test use promise.allSettled? > > Was this already failing? I think it might be a NMOS thing. Ooooh... it's actually an en-AU thing!!!! Curse you foreigners with your non USA locales!
Comment on attachment 370789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370789&action=review >>> JSTests/test262/expectations.yaml:1789 >>> + strict mode: 'Test262Error: Locale en is affected by key co; value standard. Expected SameValue(ëenû, ëen-AUû) to be true' >> >> What? Does this test use promise.allSettled? >> >> Was this already failing? > > I think it might be a NMOS thing. > > Ooooh... it's actually an en-AU thing!!!! Curse you foreigners with your non USA locales! Just realised that I forgot to add a :)
Committed r245869: <https://trac.webkit.org/changeset/245869>
Comment on attachment 370789 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370789&action=review >>>> JSTests/test262/expectations.yaml:1789 >>>> + strict mode: 'Test262Error: Locale en is affected by key co; value standard. Expected SameValue(ëenû, ëen-AUû) to be true' >>> >>> What? Does this test use promise.allSettled? >>> >>> Was this already failing? >> >> I think it might be a NMOS thing. >> >> Ooooh... it's actually an en-AU thing!!!! Curse you foreigners with your non USA locales! > > Just realised that I forgot to add a :) How dare you have the audacity to test an Internationalization API with a non-USA system locale! In all seriousness though this seems like an unfortunate bug... It's kinda weird that these results would depend on the locale though.