refactor(formatter): Remove HardSpace IR#20958
Conversation
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. |
HardSpace IR
Merging this PR will not alter performance
Comparing Footnotes
|
Merge activity
|
Refs: #20954 (comment) `HardSpace` was only used in one place in `oxc_formatter`: `TSTypeOperator` formatting (`print/mod.rs`). Replacing it with `Space` caused no issues. Biome also uses `hard_space` (via `soft_line_indent_or_hard_space`) in only one place in JS formatting. For arrow functions with conditional expression bodies. > https://github.com/biomejs/biome/blob/main/crates/biome_js_formatter/src/js/expressions/arrow_function_expression.rs#L156 However, `oxc_formatter` already uses `soft_line_indent_or_space` (not `hard_space`) for that same case, with no issues. --- I also attempted to align the `Space` handling with Ruff's approach, resolving `Space` immediately via `print_text(" ")` / `fits_text(" ")` instead of deferring it through `pending_space`. But this caused significant conformance regressions. 😓 The root cause appears to be that `oxc_formatter`'s IR generation is less strict about where `Space` elements appear (e.g., trailing spaces in `line_suffix`), relying on the Printer's deferred `pending_space` mechanism to silently discard unresolved spaces. So, leave it for now.
772e482 to
fc82a7c
Compare

Refs: #20954 (comment)
HardSpacewas only used in one place inoxc_formatter:TSTypeOperatorformatting (print/mod.rs).Replacing it with
Spacecaused no issues.Biome also uses
hard_space(viasoft_line_indent_or_hard_space) in only one place in JS formatting. For arrow functions with conditional expression bodies.However,
oxc_formatteralready usessoft_line_indent_or_space(nothard_space) for that same case, with no issues.I also attempted to align the
Spacehandling with Ruff's approach, resolvingSpaceimmediately viaprint_text(" ")/fits_text(" ")instead of deferring it throughpending_space. But this caused significant conformance regressions. 😓The root cause appears to be that
oxc_formatter's IR generation is less strict about whereSpaceelements appear (e.g., trailing spaces inline_suffix), relying on the Printer's deferredpending_spacemechanism to silently discard unresolved spaces.So, leave it for now.