internal/coverage/cfile — validation proof
Go’s own internal/coverage/cfile test suite, converted to C# by go2cs, built against the converted standard
library, run under the Go-semantics test host, and compared verdict for verdict against a clean
go test -json baseline of the same sources. This page is generated by the converter from that
comparison — it is the evidence behind the internal/coverage/cfile row in
Validated Test Packages.
Validated 2026-08-29 · converter ebb486dbc
15 matched · 1 disclosed — Go 1.23.12, windows/amd64, converted package
src/core/internal/coverage/cfile.
Both runtimes skip 1 of the matched tests identically.
Verdicts
| Test | go test |
go2cs |
|---|---|---|
TestApisOnNocoverBinary |
pass | pass |
TestAuxMetaDataFiles |
pass | pass |
TestCoverageApis |
pass | pass |
TestCoverageApis/emitToDir |
pass | pass |
TestCoverageApis/emitToDirNonAtomic |
pass | pass |
TestCoverageApis/emitToFailingWriter |
pass | pass |
TestCoverageApis/emitToNilWriter |
pass | pass |
TestCoverageApis/emitToNonexistentDir |
pass | pass |
TestCoverageApis/emitToWriter |
pass | pass |
TestCoverageApis/emitToWriterNonAtomic |
pass | pass |
TestCoverageApis/emitWithCounterClear |
pass | pass |
TestCoverageApis/emitWithCounterClearNonAtomic |
pass | pass |
TestCoverageSnapshot |
pass | pass |
TestIssue56006EmitDataRaceCoverRunningGoroutine |
skip | skip |
TestIssue59563TruncatedCoverPkgAll |
pass | fail (disclosed) |
TestTestSupport |
pass | pass |
Disclosed divergences
A disclosed divergence is a specific Go assertion the managed CLR provably cannot satisfy — not
a skipped test and not a tolerance. Each one is pinned by exact failure signature in the package’s
hand-owned go2cs_test_disclosures.json;
a disclosed test that fails any other way is still a hard mismatch.
| Test | Class | Pinned reason |
|---|---|---|
TestIssue59563TruncatedCoverPkgAll |
host-identity |
the assert requires the process’s CURRENT DIRECTORY to sit under the GOROOT the process REPORTS. The test shells out twice to the real toolchain — go test -coverpkg=all -coverprofile=… with cmd.Dir = testdata/issue59563, then go tool cover -func=… — and scans the output for one row whose path has the prefix “internal/coverage/cfile/testdata/issue59563/repro.go” and contains “large”. BOTH subprocesses SUCCEED in the converted host and the full listing is produced; the divergence is one prefix. Measured A/B, same toolchain, same command, only the run location differing: control (real GOROOT/src/internal/coverage/cfile/testdata/issue59563) -> 10280 func rows; internal/coverage/cfile/testdata/issue59563/repro.go:18: large 100.0% experiment (identical layout — staged src/go.mod plus the ancestry path — OUTSIDE the reported GOROOT) -> 10280 func rows; std/internal/coverage/cfile/testdata/issue59563/repro.go:18: large 100.0% Identical row count to the digit, identical functions, identical percentages. Outside the reported GOROOT the toolchain reads the staged src/go.mod as an ORDINARY module named std rather than as GOROOT’s own standard library, so every package path becomes module-qualified; strings.HasPrefix then fails and nfound stays 0. The coverage the test exists to check is CORRECT — large is 100.0%, which is the whole point of issue 59563 — and only the rendering of the host’s directory identity differs. The sandbox run-directory is deliberate (a test may write without touching the real tree) and PackageAncestry deliberately keeps GOROOT pointing at the real installation, because repointing it at the junction-mirrored ancestry regresses two already-validated packages that WALK GOROOT: compress/gzip’s issue14937 test and path/filepath (measured: 0 *.gz found against the real 4; 1 src/unicode entry against the real 19). Same root as go/build’s TestLocalDirectory, which the same cwd-vs-reported-GOROOT identity breaks in a different place: there ImportDir finds no known root and answers “.”, where this one gets a module-qualified std/ prefix. One cause, two manifestations. Retires if the host can place cwd under the reported GOROOT without repointing GOROOT at a junction view, or if the toolchain’s std-module identification stops depending on the directory’s position. |