fix(transformer/using): fix bindings scope mismatches

[camc314]

No description provided.

[camc314]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(transformer/using): fix bindings scope mismatches #9962 👈 (View in Graphite)
• fix(transformer/using): transform using declarations in try block #10211
• fix(transfomer/using): remove use of child ids #9961
• fix(transformer/using): correctly reparent scopes in for of stmt #9960
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camc314]

i really hate how i've done this, but it works for now.

why does ctx.insert_scope_below_statements not move the scopes of the symbols it sees? this seems like something obvious it should do (although there's probably a great reason why it doesn't), because i can't think of a situation where you would be inserting a scope but not moving the symbols scopes inside it

[overlookmotel]

Can you use Scoping data instead? Loop through the bindings of the scope and move any symbols which are block scoped.

But I may well be wrong and that doesn't work.

Unfortunately may also need to deal with BindingIdentifiers in TS* nodes e.g. TSEnumDeclaration. TS transform will remove them anyway, but if this transform moves those nodes first, the bindings need to be moved too, to avoid confusing the TS transform.

[overlookmotel]

Ah feck I think I am wrong. Presumably that wouldn't work if it's a Function, because bindings for function params shouldn't be moved. Or maybe it's OK because function params aren't block scoped?

[camc314]

apologies. i thought about replying, but forgot to!

Yes it's exactly that reason.

in this example, we've gone from:

function f(arg0) {
    using test = arg0();
}

to

function f(arg0) {
  try {
    var _usingCtx = babelHelpers.usingCtx();
    const x = _usingCtx.u(arg0());
  } catch (_) {
    _usingCtx.e = _;
  } finally {
    _usingCtx.d();
  }
}

so only the bindings inside the function body (note arg0 is in the scope but shouldn't be moved), should be moved.

My thought's are that id's be super helpful if ChildScopeCollector also returned binding ids as well as wel as the socpes that it moved. but may have to flesh it out a bit more

[camc314]

Actually, looking at ChildScopeCollector is used currently. it is never used in a scenario where the scope or bindings would change. it feels reasonable to adjust it as described above.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #9962 will degrade performances by 3.41%

_{Comparing c/03-22-fix_transformer_using_fix_bindings_scope_mismatches (5274758) with main (778b044)}

Summary

⚡ 1 improvements
❌ 1 regressions
✅ 34 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	formatter[antd.js]	7.9 ms	7.6 ms	+3.88%
❌	formatter[typescript.js]	7.2 ms	7.4 ms	-3.41%