You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test_runner: source-mapped coverage marks an unexecuted return as covered #67099
The test only calls choose(true). Original line 5 (return "no") should be uncovered. With the source-map comment removed, the JavaScript report correctly shows line 5 uncovered.
Actual behavior
The source-mapped report shows example.ts at 100% lines, 66.67% branches, and 100% functions, with no uncovered lines. The lcov reporter also emits DA:5,1. This overstates execution of a branch that the test never takes.
This reproduces with a single test process and a precompiled module. The example was generated using esbuild 0.28.2, but the reproduction above does not require esbuild. Related source-map coverage reports include #65946 and #67077; those describe off-thread hooks or merging multiple test processes, while this case needs neither.
i've been looking into this and have a local change that fixes the repro. the mapped zero-count range stops before the end of the return line, so the line stays covered.
i found the same problem with an uncalled function too, plus a few other boundary cases with sparse maps. trying to cover those also broke some reports that were previously correct.
i'm still working out whether a small endpoint fix is enough here or the other boundary cases need to be addressed in the same change.
Activity
fatihguzeldev commentedon Oct 31, 2026
i've been looking into this and have a local change that fixes the repro. the mapped zero-count range stops before the end of the return line, so the line stays covered.
i found the same problem with an uncalled function too, plus a few other boundary cases with sparse maps. trying to cover those also broke some reports that were previously correct.
i'm still working out whether a small endpoint fix is enough here or the other boundary cases need to be addressed in the same change.