refactor(transformer/using): remove unused call to enter_block_statement

[overlookmotel]

ExplicitResourceManagement has no enter_block_statement method.

[overlookmotel]

• refactor(transformer/using): remove unused call to enter_block_statement #9698 👈 (View in Graphite)
• 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.

[codspeed-hq]

CodSpeed Performance Report

Merging #9698 will not alter performance

_{Comparing 03-12-refactor_transformer_using_remove_unused_call_to_enter_block_statement_ (0903e7e) with main (3d4400c)}

Summary

✅ 33 untouched benchmarks

[camc314]

Merge activity

• Mar 12, 5:03 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 12, 5:03 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 12, 5:17 AM EDT: A user merged this pull request with the Graphite merge queue.

[camc314]

@overlookmotel would it be better if the transforms didn't implement the trait, and instead just had pub fn enter..., this way we'd catch these errors at compile time, rather than manually with our eyes

[overlookmotel]

Yes maybe. The idea was to impose some consistency/order on transformers by mandating that they implement all their "entry points" as an impl Traverse. I do think that has some merit, but this is the unfortunate downside.

The only cost of making a mistake is bad code style. As the default methods in Traverse trait are all empty and all marked #[inline] any redundant calls will be completely optimized out. So there's no perf cost.

The mistake fixed in #9692 (which did have a perf impact) would not have been caught except by eye either way.

So... hmm... maybe, maybe not!