chore(tasks): enable enum_eval for transformer-fed semantic builders#22253
Merged
graphite-app[bot] merged 1 commit intoMay 9, 2026
Merged
Conversation
3 tasks
Merging this PR will not alter performance
Comparing Footnotes
|
Member
Author
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
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. |
sapphi-red
approved these changes
May 8, 2026
Member
Author
Merge activity
|
#22253) Pre-requisite for #22252. ## Why #22252 adds a `debug_assert!` in the transformer that requires `Scoping` to be built with `SemanticBuilder::with_enum_eval(true)` whenever a `TSEnumDeclaration` reaches the transform pass. The internal `Compiler` (`crates/oxc/src/compiler.rs`) and the playground already enable it; the CI run on #22252 surfaced a few internal callers that don't. Land that fix on its own first, so the assert PR doesn't trip CI on these tasks. ## Sites updated Every `SemanticBuilder` site that feeds `Transformer::build_with_scoping`: - `tasks/track_memory_allocations/src/lib.rs` — both call sites (`cargo allocs`). - `tasks/benchmark/benches/transformer.rs` - `tasks/benchmark/benches/pipeline.rs` - `tasks/benchmark/benches/minifier.rs` - `tasks/benchmark/benches/codegen.rs` Other semantic builders in these files that feed only the minifier / codegen / compressor are left alone — they don't go through enum lowering. ## Test plan - [x] `cargo check -p oxc_track_memory_allocations` — clean - [x] `cargo check --benches -p oxc_benchmark` — clean
b8ca72b to
6749b02
Compare
graphite-app Bot
pushed a commit
that referenced
this pull request
May 10, 2026
…mantic (#22252) Closes #21667. Stacked on #22253 (which lands the prerequisite `with_enum_eval(true)` calls in `cargo allocs` and the four transformer benches that this assert would otherwise trip). ## Problem The TS enum lowering reads pre-computed member values from `Scoping`. Those values are only populated when `SemanticBuilder::with_enum_eval(true)` is set; without it, every `get_enum_member_value` call returns `None`, so string-valued members are treated as opaque expressions and the transform emits incorrect reverse mappings. Example from #21667: ```ts enum Theme { Light = "Light", Dark = "Dark", Default = Theme.Light, } ``` When the transformer runs on a `Scoping` built without `enum_eval`, it does not recognise `Theme.Light` as a string and produces: ```js Theme[Theme["Default"] = Theme.Light] = "Default"; ``` — i.e. a reverse-mapping assignment for a string member, which is wrong (and runtime-observable). ## Fix Add a `debug_assert!` at the entry of `transform_ts_enum` (after the `decl.declare` early return) verifying that the enum's body scope is registered in `Scoping`. The check uses `get_enum_body_scopes` as the signal: `add_enum_body_scope` has exactly one caller (`evaluate_enum_members`), which is gated entirely by `enum_eval`. No new state on `Scoping` / `EnumData`. The internal `Compiler` (`crates/oxc/src/compiler.rs`) and the playground (`napi/playground/src/lib.rs`) already enable `enum_eval`. The benches and `cargo allocs` are fixed in the parent PR. This guard catches the misuse for any other external caller of `Transformer::build_with_scoping`. ## Test plan - [x] `cargo test -p oxc_transformer` — new integration tests in `tests/integrations/enum_eval.rs` cover both the positive case and the `#[should_panic]` case (debug-only) - [x] `cargo run -p oxc_transform_conformance` — no snapshot changes (the conformance runner goes through `CompilerInterface`, which already enables `enum_eval`) - [x] `cargo clippy -p oxc_transformer --tests` — clean
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Pre-requisite for #22252.
Why
#22252 adds a
debug_assert!in the transformer that requiresScopingto be built withSemanticBuilder::with_enum_eval(true)whenever aTSEnumDeclarationreaches the transform pass. The internalCompiler(crates/oxc/src/compiler.rs) and the playground already enable it; the CI run on #22252 surfaced a few internal callers that don't.Land that fix on its own first, so the assert PR doesn't trip CI on these tasks.
Sites updated
Every
SemanticBuildersite that feedsTransformer::build_with_scoping:tasks/track_memory_allocations/src/lib.rs— both call sites (cargo allocs).tasks/benchmark/benches/transformer.rstasks/benchmark/benches/pipeline.rstasks/benchmark/benches/minifier.rstasks/benchmark/benches/codegen.rsOther semantic builders in these files that feed only the minifier / codegen / compressor are left alone — they don't go through enum lowering.
Test plan
cargo check -p oxc_track_memory_allocations— cleancargo check --benches -p oxc_benchmark— clean