Skip to content
This repository has been archived by the owner on Oct 8, 2024. It is now read-only.

Calling return() on a suspendedStart iterator helper doesn't seem to call return() on the underlying #266

Closed
syg opened this issue Feb 15, 2023 · 2 comments · Fixed by #267

Comments

@syg
Copy link

syg commented Feb 15, 2023

Iterator helpers are specified as generators whose bodies are Abstract Closures. That is, they start in a suspendedStart state until one of its step methods is called. If you call return() on a helper before next(), this goes to GeneratorResumeAbrupt, which has a fast path for going from suspendedStart -> completed without evaluating anything. AFAICT this won't call return() on the underlying, which is the intention.

@bakkot
Copy link
Collaborator

bakkot commented Feb 15, 2023

Agreed that this is a bug.

I think this can be fixed by adding a special case for suspendedStart in %IteratorHelperPrototype%.return ( ), though it will require moving the iterated record from a captured alias to a slot on the object. (Which is annoying, because the objects are created by CreateIteratorFromClosure, which doesn't currently allow you to specify additional slots on the created object.)

@syg

This comment was marked as resolved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants