fix(runtime): Promise resolving-functions [[AlreadyResolved]] guard + combinators#4745
Merged
Conversation
- Implement CreateResolvingFunctions (ECMA-262 27.2.1.3): the resolve/reject pair handed to an executor now share one [[AlreadyResolved]] cell, so once either fires the other is a no-op — even while the promise is still pending (resolve called with an unsettled thenable, then a later reject must be ignored). The state!=Pending check alone could not model this. - resolve assimilates thenables/promises and rejects self-resolution. - Promise.all/allSettled/race/any combinator fixes (combinators.rs). - closure capture read is bounds-guarded so optional captures (the shared guard in slot 1) can be probed on closures allocated with fewer slots.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes
built-ins/Promise(baseline 402/574, 70%) by modeling resolving-function semantics correctly.Root causes
[[AlreadyResolved]]guard (ECMA-262 27.2.1.3 CreateResolvingFunctions). The resolve/reject pair given to an executor must share ONE boolean — once either fires, the other is a no-op, even while the promise is still pending (e.g.resolve(thenable)leaves the promise pending while the thenable job runs, but a laterreject(x)must be ignored). Thestate != Pendingcheck alone can't model this; added an explicit shared guard cell captured by both closures.Promise.all/allSettled/race/any(combinators.rs).Files
promise/combinators.rs,promise/spec_combinators.rs,closure/alloc.rsDelta confirmed by post-merge resweep. (No version/CHANGELOG bump — maintainer folds in.)