Generated `.cpuprofile` `lineNumber`/`columnNumber` usage mismatches `node` and `deno`

[TomerAberbach]

What version of Bun is running?

1.3.9+cf6cdbbba

What platform is your computer?

Darwin 23.6.0 arm64 arm

What steps can reproduce the bug?

Run bun --cpu-prof some-script.js

In this case, bun produces a .cpuprofile file that uses the lineNumber and columnNumber fields in the JSON for the line/column where the CPU was at the time of the sample.

However, this doesn't match what node and deno use those fields for. node and deno both use lineNumber and columnNumber for where the function where the sample was taken was defined. They then use a separate positionTicks field for noting lines within the function where samples were taken.

What is the expected behavior?

I would expect bun's output to match node and deno's because:

1. Then I can write my .cpuprofile processing code one way and have it work for node, deno, and bun
2. When processing the profile, I can reliably determine whether two nodes are for the same function and merge them together if I want (by keying on functionName, url, lineNumber, and columnNumber). With bun's format this is pretty much impossible. Keying on functionName and url is insufficient because you could have two functions with the same name in the same file.

What do you see instead?

See above for explanation

Additional information

Sorry that this report is not with the latest version. I'm on a plane and can't install the latest 😅

I did, however, check the release notes for versions since 1.3.9 and didn't see anything related to this.

[robobun]

✅ Reproduced and fixed — bun --cpu-prof now emits callFrame.lineNumber / callFrame.columnNumber for the function DEFINITION (0-indexed, like Node/Deno) and positionTicks: [{line, ticks}, ...] for per-sample lines. Sourcemapped sources (e.g. transpiled .ts) report the original source URL consistently. Recursive fibonacci workload: 1200+ fragmented nodes → ~30, merge-by-callFrame works. Fix in #29241.