Add using and await using Declarations, SuppressedError, DisposableStack, and AsyncDisposableStack

[rbuckton]

This PR contains the Stage 3 specification text for Explicit Resource Management.

[rbuckton]

I'm not quite sure how to address the remaining esmeta issues.

[jmdyck]

Rather than suggest changes here, I've made a PR against this PR's branch: rbuckton#2

[rbuckton]

This last commit adds a few UpdateEmpty calls that aren't strictly necessary, but esmeta doesn't quite understand what's happening without it. I also had to switch AO parameters typed : a function object to : an ECMAScript language value since IsCallable doesn't seem to act as a type guard.

[bakkot]

@rbuckton Sorry about that - esmeta is still a little imprecise. You should feel free to write the spec text you want and not worry about esmeta's errors, and we can update esmeta or the ignore file.

[rbuckton]

@rbuckton Sorry about that - esmeta is still a little imprecise. You should feel free to write the spec text you want and not worry about esmeta's errors, and we can update esmeta or the ignore file.

I replaced the UpdateEmpty calls with a few asserts that seem to be accurate. For example, in ForIn/OfBodyEvaluation, if status is abrupt going in to DisposeResources, it should still be abrupt on the way out. Likewise, ForBodyEvaluation won't return a normal completion for empty, so DisposeResources shouldn't produce one either.

[rbuckton]

Please note, I've created rbuckton#3 as a separate PR against this one containing the additional specification changes that would be necessary to support https://github.com/tc39/proposal-async-explicit-resource-management, should it advance to Stage 3.

[rbuckton]

I found an issue with the change in e4f2d05 to use an EE to restrict binding patterns, in that it results in an ambiguous parse of using[x] before the EE can be applied, which was not intended.

I've filed tc39/proposal-explicit-resource-management#152 against the proposal spec, and will update this PR in due time.

[rbuckton]

I found an issue with the change in e4f2d05 to use an EE to restrict binding patterns, in that it results in an ambiguous parse of using[x] before the EE can be applied, which was not intended.

I've filed tc39/proposal-explicit-resource-management#152 against the proposal spec, and will update this PR in due time.

tc39/proposal-explicit-resource-management#152 has merged, and I've amended this PR to match as part of 3044fd9.

[rbuckton]

This now includes the await using declaration and AsyncDisposableStack, per prior consensus (incl. the March 2023 plenary).

[rbuckton]

Note to implementers: There is a typo in GetDisposeMethod that will be addressed by tc39/proposal-explicit-resource-management#217. The typo was introduced as part of a normative change that reached consensus in July 2023, but fixing it is also a potentially a normative change and may require additional consensus.

[rbuckton]

This is also missing the consensus change to use await using as the syntactic head for the asynchronous form of the using declaration. That will be up shortly.

[rbuckton]

25f1bc4 applies changes from the following PRs which previously achieved consensus in March 2023 and July 2023:

• Ignore return value of [Symbol.dispose]() method when hint is 'async-dispose' proposal-explicit-resource-management#180
• Move DisposeResources to Evaluation of FunctionStatementList proposal-explicit-resource-management#178
• Add missing calls to NewDisposeCapability AOs proposal-explicit-resource-management#175
• Correctly use hint in ForIn/OfBodyEvaluation proposal-explicit-resource-management#171
• Add missing .prototype property entries for DisposableStack/AsyncDisposableStack proposal-explicit-resource-management#167
• Merge async proposal back into sync proposal proposal-explicit-resource-management#154
• Revert 'await' restriction proposal-explicit-resource-management#153

[jmdyck]

Oh, also, the things in Annex A should parallel how they appear in the main body.

Are you referring to the placement of the "Supplemental Syntax" section, or something else?

The placement of the two new Supplemetal Syntaxes, for UnaryExpression and AwaitUsingDeclaration pieces would mostly account for the differences I'm seeing.

Also, in the latter, the main body says "When processing an instance...", but Annex A says " In certain circumstances when processing an instance..."

[rbuckton]

Oh, also, the things in Annex A should parallel how they appear in the main body.

Are you referring to the placement of the "Supplemental Syntax" section, or something else?

The placement of the two new Supplemetal Syntaxes, for UnaryExpression and AwaitUsingDeclaration pieces would mostly account for the differences I'm seeing.

Also, in the latter, the main body says "When processing an instance...", but Annex A says " In certain circumstances when processing an instance..."

UnaryExpression was certainly off as I needed to move the supplemental syntax from where it was at one point under Async Functions. Other than the wording for AwaitUsingDeclaration the Annex A position of seems correct to me, so I'm not clear on what's wrong there. In the main body the grammar goes LexicalDeclaration, LetOrConst, UsingDeclaration, and then AwaitUsingDeclaration, which is the same order in the annex.

[jmdyck]

UnaryExpression was certainly off as I needed to move the supplemental syntax from where it was at one point under Async Functions. Other than the wording for AwaitUsingDeclaration the Annex A position of seems correct to me, so I'm not clear on what's wrong there.

I'll have another look at some point.

There's also some weirdness in the SDO coverage, but it might be my code, so that'll take a while to investigate.