Editorial: Eliminate weird `Return` notes

[jmdyck]

That is, eliminate NOTE-steps that tell you where a Return-step returns to.

Resolves #2400 by performing the transformation outlined in https://github.com/tc39/ecma262/issues/2400#issuecomment-832335872

This PR goes in roughly the same direction as #2429, but not as far, so maybe it has a better chance of being approved.

[bakkot]

This PR goes in roughly the same direction as https://github.com/tc39/ecma262/pull/2429, but not as far, so maybe it has a better chance of being approved.

#2429 is mostly just waiting for us to finish #2547; it's not that anyone had a problem with it.

[jmdyck]

Oh, that reminds me, I had some problems with it ... :)

[michaelficarra]

Summary from editor call today is that we should separate out the deduplication (into its own PR if you want) and focus on the step refactoring. For all existing cases of this usage of "resume", we'd like to instead use a new phrasing that explicitly mentions a transfer of control.

[bakkot]

Probably in addition to "resume"; that is, both resume the execution context and then explicitly transfer control to it.

[jmdyck]

Summary from editor call today is that we should separate out the deduplication (into its own PR if you want) and focus on the step refactoring.

Okay, I've reset this branch back to the first commit.

For all existing cases of this usage of "resume", we'd like to instead use a new phrasing that explicitly mentions a transfer of control.

That's fine with me, but are you saying you'd like that in this PR?

The point of this PR is to eliminate the need for the weird Return notes -- it only touches the 3 'yield-side' transfers of control, and uses pre-existing terminology.

I believe you're talking about including the 6 'next-side' transfers, and introducing new terminology (which you'd presumably want defined/explained). I'm happy to do that work, but it seems like a distinct PR to me.

---

Also, I'll point out that that PR will be easier if we first refactor all the control-transfers and associated execution-stack manipulations down to 2 abstract operations, e.g.:

• RunSuspendedContext for the next-side (see PR #2664), and
• RunCallerContext for the yield-side (from the original form of this PR).

In the editors' call, there seemed to be some opposition to this plan, but I didn't really catch why.

[bakkot]

In the editors' call, there seemed to be some opposition to this plan, but I didn't really catch why.

There is always a cost to factoring stuff out, which is that it adds a layer of indirection before you can see what's actually being done. In this case, because the operation is quite rare and the thing the operation does is extremely weird, I don't think that cost is worth it.