Read coverage counts as Int64, narrowing only at the vendored boundary

[davidanthoff]

Every x86 leg that runs with coverage errors on whatever test item happens to be running when the counters are collected — for example on CSTParser's ubuntu-latest, 1.12.7~x86 leg:

OverflowError: overflow parsing "2345022144"
  at readfile (packages/CoverageTools/src/lcov.jl:99)

collect_coverage_data! writes the runtime's counters with jl_write_coverage_data and reads them straight back with CoverageTools.LCOV.readfile. Julia's counters are 64 bit whatever the word size, and a line in a hot loop passes typemax(Int32) easily, but the count was parsed as Int — Int32 on a 32 bit platform — so the value the runtime had just written did not fit.

This replaces the first version of this PR, which fixed it by editing packages/CoverageTools. That was wrong: packages/ holds git subtrees that are never edited by hand, and scripts/update_vendored_packages.jl deliberately skips CoverageTools ("newer versions have a dependency on JuliaSyntax"), so there is no re-vendoring route either. Nothing under packages/ is touched now.

Instead the file is read here. shared/coverage_counts.jl parses the same SF:/DA: lines LCOV.readfile does, accumulating in Int64, and narrows a count only where it crosses into a vendored FileCoverage — where it saturates rather than throwing, because knowing a line ran at least 2147483647 times beats losing the run over the exact figure. The controller applies the same narrowing to counts arriving over the wire, so a 64 bit test process reporting to a 32 bit controller cannot throw an InexactError either.

The protocol's FileCoverage now carries Int64, so the JSON payload does not depend on either side's word size. TestrunResultFileCoverage stays at Int: what reaches it comes out of the vendored merge_coverage_counts, which produces Int whatever we declare.

Verified locally on both word sizes — the coverage and LCOV test items, 14/14 under the default channel and 14/14 under --juliaup-channel 1.12~x86. The new test item builds a synthetic LCOV file with a count above typemax(Int32) and checks it survives where Int is 64 bit and saturates where it is not.

This is not specific to Julia 1.13 — the same legs fail on 1.12. It was simply never visible until the rc legs started running at all, and the failure lands on an unrelated test item, which is why it read as a parser problem in CSTParser. It plausibly accounts for the rc~x86 reds on JuliaWorkspaces and LanguageServer too.

Found while auditing the stack for Julia 1.13 readiness.

🤖 Generated with Claude Code