Skip to content

fix(codegen): emit call end mapping at ) position, not past it#22199

Merged
graphite-app[bot] merged 1 commit into
mainfrom
fix/codegen-call-end-mapping-position
May 7, 2026
Merged

fix(codegen): emit call end mapping at ) position, not past it#22199
graphite-app[bot] merged 1 commit into
mainfrom
fix/codegen-call-end-mapping-position

Conversation

@Dunqing

@Dunqing Dunqing commented May 7, 2026

Copy link
Copy Markdown
Member

Follow-up on #22001.

Move add_source_mapping_end(span) to before print_ascii_byte(b')') in print_arguments so the call's end mapping lands at the generated position of ) rather than one past it. Each generated paren now has at most one mapping at its exact position, matching the convention used by esbuild and Babel.

A second follow-up (#22200) extends the same fix to block-end }, curly-braces }, and the ]/} of ArrayExpression / ObjectExpression.

Why

After #22001, add_source_mapping_end correctly points the source side at span.end - 1 (the closing source char), but the generated position was still placed AFTER ) was printed. For chained calls like factory()(), this collided with the next AST node's start position:

  • inner call's end mapping at gen 7:9 → src 7:8 (just past inner ))
  • the outer call's ( lives at gen 7:9 in the generated code

Result: a V8 stack-trace lookup at gen 7:9 (the outer () returned src 7:8 (the inner )) — one column off.

How

Emit the end mapping at the gen position of ), not after it. Now:

  • gen 7:8 → src 7:8 (inner ))
  • gen 7:9 has no direct mapping → falls back to inner end → src 7:8
  • gen 7:10 → src 7:10 (outer ))

The chained-call shadow at the outer ( becomes a plain "no mapping here, fall back to inner )" — same accepted behavior as esbuild, Babel, and TypeScript. None of them special-case chained calls.

Visual comparisons

Generated against a fixture covering classes, arrow bodies, arrays, objects, and chained calls in the source-map viewer:

Reference

esbuild (internal/js_printer/js_printer.go):

if e.CloseParenLoc.Start > expr.Loc.Start {
    p.addSourceMapping(e.CloseParenLoc)
}
p.print(")")

Babel (packages/babel-generator/src/printer.ts::rightParens):

this.sourceWithOffset("end", node.loc, -1);
this.token(")");

Test plan

  • New test call_end_mapping_lands_at_close_paren — pins both ) mappings of factory()() to their close-paren positions
  • cargo test -p oxc_codegen passes (99 tests)
  • stacktrace_is_correct snapshot unchanged

@github-actions github-actions Bot added the A-codegen Area - Code Generation label May 7, 2026

Dunqing commented May 7, 2026

Copy link
Copy Markdown
Member Author

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 changes, fast-track this PR to the front of 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.

@Dunqing Dunqing changed the title feat(linter): split jest/no-test-prefixes into separate vitest rule (#21876) fix(codegen): emit call end mapping at ) position, not past it May 7, 2026
@Dunqing Dunqing force-pushed the fix/codegen-call-end-mapping-position branch from fd6669d to 9d686ff Compare May 7, 2026 03:27
@codspeed-hq

codspeed-hq Bot commented May 7, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 48 untouched benchmarks
⏩ 3 skipped benchmarks1


Comparing fix/codegen-call-end-mapping-position (5fa194c) with main (7bb00dd)

Open in CodSpeed

Footnotes

  1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@Dunqing Dunqing force-pushed the fix/codegen-call-end-mapping-position branch from 9d686ff to be80fc2 Compare May 7, 2026 03:35
@Dunqing Dunqing changed the title fix(codegen): emit call end mapping at ) position, not past it fix(codegen): emit close-delimiter end mappings at the delim, not past it May 7, 2026
@Dunqing Dunqing force-pushed the fix/codegen-call-end-mapping-position branch from be80fc2 to dfd2d97 Compare May 7, 2026 03:47
@Dunqing Dunqing changed the title fix(codegen): emit close-delimiter end mappings at the delim, not past it fix(codegen): emit call end mapping at ) position, not past it May 7, 2026
@Dunqing Dunqing force-pushed the fix/codegen-call-end-mapping-position branch 2 times, most recently from 932cd2f to 5fa194c Compare May 7, 2026 04:22
@Dunqing Dunqing marked this pull request as ready for review May 7, 2026 05:27
@Dunqing Dunqing requested a review from overlookmotel as a code owner May 7, 2026 05:27
@Dunqing Dunqing requested review from Boshen and sapphi-red May 7, 2026 05:28
@graphite-app graphite-app Bot added the 0-merge Merge with Graphite Merge Queue label May 7, 2026
@graphite-app

graphite-app Bot commented May 7, 2026

Copy link
Copy Markdown
Contributor

Merge activity

graphite-app Bot pushed a commit that referenced this pull request May 7, 2026
)

Follow-up on #22001.

Move `add_source_mapping_end(span)` to before `print_ascii_byte(b')')` in `print_arguments` so the call's end mapping lands at the generated position **of** `)` rather than one past it. Each generated paren now has at most one mapping at its exact position, matching the convention used by esbuild and Babel.

A second follow-up (#22200) extends the same fix to block-end `}`, curly-braces `}`, and the `]`/`}` of `ArrayExpression` / `ObjectExpression`.

## Why

After #22001, `add_source_mapping_end` correctly points the source side at `span.end - 1` (the closing source char), but the generated position was still placed AFTER `)` was printed. For chained calls like `factory()()`, this collided with the next AST node's start position:

- inner call's end mapping at `gen 7:9 → src 7:8` (just past inner `)`)
- the outer call's `(` lives at `gen 7:9` in the generated code

Result: a V8 stack-trace lookup at `gen 7:9` (the outer `(`) returned `src 7:8` (the inner `)`) — one column off.

## How

Emit the end mapping at the gen position **of** `)`, not after it. Now:

- `gen 7:8 → src 7:8` (inner `)`)
- `gen 7:9` has no direct mapping → falls back to inner end → `src 7:8`
- `gen 7:10 → src 7:10` (outer `)`)

The chained-call shadow at the outer `(` becomes a plain "no mapping here, fall back to inner `)`" — same accepted behavior as esbuild, Babel, and TypeScript. None of them special-case chained calls.

## Visual comparisons

Generated against a fixture covering classes, arrow bodies, arrays, objects, and chained calls in the [source-map viewer](https://source-map-viewer.void.app):

- **Pre-PR vs Full fix** (full picture): https://source-map-viewer.void.app/compare?a=j9GHxMTX&b=UcCYKDih
- **PR-only vs Full fix** (just the changes #22199 + #22200 add): https://source-map-viewer.void.app/compare?a=ngs4XAsh&b=UcCYKDih
- **esbuild vs Full fix** (alignment with esbuild): https://source-map-viewer.void.app/compare?a=26JVF9DI&b=UcCYKDih

## Reference

esbuild (`internal/js_printer/js_printer.go`):

```go
if e.CloseParenLoc.Start > expr.Loc.Start {
    p.addSourceMapping(e.CloseParenLoc)
}
p.print(")")
```

Babel (`packages/babel-generator/src/printer.ts::rightParens`):

```ts
this.sourceWithOffset("end", node.loc, -1);
this.token(")");
```

## Test plan

- [x] New test `call_end_mapping_lands_at_close_paren` — pins both `)` mappings of `factory()()` to their close-paren positions
- [x] `cargo test -p oxc_codegen` passes (99 tests)
- [x] `stacktrace_is_correct` snapshot unchanged
@graphite-app graphite-app Bot force-pushed the fix/codegen-call-end-mapping-position branch from 5fa194c to d251ae7 Compare May 7, 2026 05:39
)

Follow-up on #22001.

Move `add_source_mapping_end(span)` to before `print_ascii_byte(b')')` in `print_arguments` so the call's end mapping lands at the generated position **of** `)` rather than one past it. Each generated paren now has at most one mapping at its exact position, matching the convention used by esbuild and Babel.

A second follow-up (#22200) extends the same fix to block-end `}`, curly-braces `}`, and the `]`/`}` of `ArrayExpression` / `ObjectExpression`.

## Why

After #22001, `add_source_mapping_end` correctly points the source side at `span.end - 1` (the closing source char), but the generated position was still placed AFTER `)` was printed. For chained calls like `factory()()`, this collided with the next AST node's start position:

- inner call's end mapping at `gen 7:9 → src 7:8` (just past inner `)`)
- the outer call's `(` lives at `gen 7:9` in the generated code

Result: a V8 stack-trace lookup at `gen 7:9` (the outer `(`) returned `src 7:8` (the inner `)`) — one column off.

## How

Emit the end mapping at the gen position **of** `)`, not after it. Now:

- `gen 7:8 → src 7:8` (inner `)`)
- `gen 7:9` has no direct mapping → falls back to inner end → `src 7:8`
- `gen 7:10 → src 7:10` (outer `)`)

The chained-call shadow at the outer `(` becomes a plain "no mapping here, fall back to inner `)`" — same accepted behavior as esbuild, Babel, and TypeScript. None of them special-case chained calls.

## Visual comparisons

Generated against a fixture covering classes, arrow bodies, arrays, objects, and chained calls in the [source-map viewer](https://source-map-viewer.void.app):

- **Pre-PR vs Full fix** (full picture): https://source-map-viewer.void.app/compare?a=j9GHxMTX&b=UcCYKDih
- **PR-only vs Full fix** (just the changes #22199 + #22200 add): https://source-map-viewer.void.app/compare?a=ngs4XAsh&b=UcCYKDih
- **esbuild vs Full fix** (alignment with esbuild): https://source-map-viewer.void.app/compare?a=26JVF9DI&b=UcCYKDih

## Reference

esbuild (`internal/js_printer/js_printer.go`):

```go
if e.CloseParenLoc.Start > expr.Loc.Start {
    p.addSourceMapping(e.CloseParenLoc)
}
p.print(")")
```

Babel (`packages/babel-generator/src/printer.ts::rightParens`):

```ts
this.sourceWithOffset("end", node.loc, -1);
this.token(")");
```

## Test plan

- [x] New test `call_end_mapping_lands_at_close_paren` — pins both `)` mappings of `factory()()` to their close-paren positions
- [x] `cargo test -p oxc_codegen` passes (99 tests)
- [x] `stacktrace_is_correct` snapshot unchanged
@graphite-app graphite-app Bot force-pushed the fix/codegen-call-end-mapping-position branch from d251ae7 to a099b03 Compare May 7, 2026 05:41
@graphite-app graphite-app Bot merged commit a099b03 into main May 7, 2026
28 checks passed
@graphite-app graphite-app Bot removed the 0-merge Merge with Graphite Merge Queue label May 7, 2026
@graphite-app graphite-app Bot deleted the fix/codegen-call-end-mapping-position branch May 7, 2026 05:45
graphite-app Bot pushed a commit that referenced this pull request May 7, 2026
Stacked on #22199.

Extends the same fix shape from #22199 (move `add_source_mapping_end` before the closing `print_ascii_byte`) to the remaining close-delimiter sites: `print_block_end`, `print_curly_braces`, and the `]`/`}` of `ArrayExpression` / `ObjectExpression`.

## Why

#22199 fixed the call's `)`. The same root cause exists for `}` of blocks/objects and `]` of arrays — the end mapping was placed AFTER the close char, putting it at the position of whatever follows. The most visible case: `() => { ... };` — the source `}` mapped to the generated `;` rather than the generated `}`, so source-map consumers viewing this diff saw the `}` "point at the semicolon."

## How

Five sites total, four in this PR (one already in #22199):

| Site | File |
|---|---|
| `print_block_end` (the `}` of `BlockStatement`) | `lib.rs` |
| `print_curly_braces` (shared by class body, switch, TS enum/interface/typeliteral/module) | `lib.rs` |
| `ArrayExpression` (`]`) | `gen.rs` |
| `ObjectExpression` (`}`) | `gen.rs` |

Each: swap `print_ascii_byte; add_source_mapping_end` → `add_source_mapping_end; print_ascii_byte`. The mapping now lands at the gen position OF the close char.

## Visual comparisons

Fixture covering all 5 sites (classes, arrow bodies, arrays, objects, chained calls):

- **Pre-PR vs Full fix** (full picture): https://source-map-viewer.void.app/compare?a=j9GHxMTX&b=UcCYKDih
- **PR-only vs Full fix** (just the changes #22199 + #22200 add): https://source-map-viewer.void.app/compare?a=ngs4XAsh&b=UcCYKDih
- **esbuild vs Full fix** (alignment with esbuild): https://source-map-viewer.void.app/compare?a=26JVF9DI&b=UcCYKDih

## Reference

esbuild (`internal/js_printer/js_printer.go`):

```go
if e.CloseBraceLoc.Start > expr.Loc.Start {
    p.addSourceMapping(e.CloseBraceLoc)
}
p.print("}")
```

(Same pattern as the call's `)` handling — see #22199.)

## Test plan

Each of the 4 modified sites has direct test coverage:

- [x] `block_end_mapping_lands_at_close_brace` — pins `}` of `() => { return 1 }` (exercises `print_block_end`)
- [x] `class_body_close_brace_lands_at_close_brace` — pins `}` of `class C { a; }` (exercises `print_curly_braces` — shared by classes, switch, TS enum/interface/typeliteral/module)
- [x] `array_close_bracket_lands_at_close_bracket` — pins `]` of `const a = [1, 2]` (exercises `ArrayExpression`)
- [x] `object_close_brace_lands_at_close_brace` — pins `}` of `const o = { a: 1 }` (exercises `ObjectExpression`)
- [x] `synthesized_block_closing_braces_are_mapped` (added by #22001) updated to assert `dst (2, 0)` instead of `(2, 1)` — same intent (the synthesized `}` resolves back to the wrapped if's last char), now anchored at the `}` itself
- [x] `cargo test -p oxc_codegen` passes (11 sourcemap tests, 100 integration total)
- [x] `stacktrace_is_correct` snapshot unchanged

Each new test was verified to fail without the corresponding swap and pass with it.
graphite-app Bot pushed a commit that referenced this pull request May 7, 2026
Independent of #22199 / #22200. Fixes a separate sourcemap-indent issue.

Five `gen.rs` impls for top-level declarations were calling `add_source_mapping(self.span)` *before* `print_indent()`:

- `Directive`
- `ImportDeclaration`
- `ExportNamedDeclaration`
- `ExportAllDeclaration`
- `ExportDefaultDeclaration`

The mapping then anchored at the line's indent column (col 0) rather than at the actual keyword column. Sourcemap consumers querying the keyword's gen position would land on the leading whitespace.

Every other indented statement in the codebase (`ExpressionStatement`, `IfStatement`, `VariableDeclaration`, etc.) uses the inverse order — `print_indent` first, then `add_source_mapping`. This PR brings the five outliers in line.

## Visual comparison

The bug surfaces when codegen is invoked with non-zero `initial_indent` (a common pattern for bundler callers that nest output in a wrapper). [Before vs After this PR](https://source-map-viewer.void.app/compare?a=5KX8dYtn&b=ZFhNIEAv) on a fixture with all five declaration kinds:

```js
"use strict";
import { x } from "x";
export { y } from "y";
export * from "z";
export default 42;
```

Each declaration's source position now maps to gen col 1 (the keyword) instead of gen col 0 (the leading tab).

## Test plan

- [x] New test `top_level_decl_mappings_start_after_generated_indent` — wraps a `"use strict"`, `import`, three `export` forms inside an indented `if (true) { ... }` block, asserts each maps from `src col 0` to `gen col 1` (after the tab), not `gen col 0`.
- [x] Verified the test fails without the fix.
- [x] All 99 codegen tests pass.
camc314 added a commit that referenced this pull request May 11, 2026
### 🚀 Features

- 66c9b01 transformer/typescript: Debug_assert that `enum_eval` ran in
semantic (#22252) (Dunqing)
- ffe6475 minifier: Fold `Array` constructor with safe spreads (#22215)
(camc314)

### 🐛 Bug Fixes

- d3d0b18 traverse: Handle `ChainElement::TSNonNullExpression` in
`GatherNodeParts` (#22247) (leaysgur)
- 4e880de transformer/object-rest-spread: Declare temp vars for computed
keys (#22284) (camc314)
- a7c3e22 semantic: Clear member write target for computed keys (#22302)
(camc314)
- 6a8852d codegen: Emit newline after legal-comment orphan flush
(#22304) (Dunqing)
- 5da9fda transformer/explicit-resource-management: Preserve class names
(#22306) (Dunqing)
- b5d970f transformer/explicit-resource-management: Preserve class names
(#22290) (camc314)
- bc54fd4 minifier: Keep function / class names if direct eval is
present in the scope (#22241) (sapphi-red)
- 7a810c0 minifier: Refresh direct eval flags after DCE (#21787)
(Dunqing)
- dd88726 transformer/legacy-decorator: Preserve accessor type
annotation for emitDecoratorMetadata (#21966) (Dunqing)
- 29a3cd7 codegen: Swap mapping/indent order for top-level decls
(#22206) (Dunqing)
- 73b4f40 minifier: Preserve catch binding with direct eval (#22221)
(camc314)
- 0e13d17 minifier: Preserve optional chain base side effects (#22219)
(camc314)
- 0c7c01c transformer/typescript: Inline optional-chain enum member
access (#21834) (Dunqing)
- a6aff7e codegen: Emit block/array/object end mapping at close char
(#22200) (Dunqing)
- a099b03 codegen: Emit call end mapping at `)` position, not past it
(#22199) (Dunqing)
- 5753774 minifier: Cap if-return ternary collapse for firefox (#21841)
(Gurupungav Narayanan)
- 2493bdd codegen: Correct sourcemap end mappings for closing delimiters
(#22001) (Mark Dalgleish)
- 3b385e2 minifier: Bail optimizing `Array` with unknown arg count
(#22188) (camc314)
- 9fa2122 parser: Parse array computed class keys (#22159) (camc314)

### 📚 Documentation

- a4a6892 napi/parser: Correct code comment (#22278) (overlookmotel)
- 9305373 oxc: Update README (#22178) (camc314)

Co-authored-by: Cameron <cameron.clark@hey.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-codegen Area - Code Generation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant