cmd/cover: provide a mechanism to flush out coverage report

[matloob]

In some cases, such as golang.org/x/tools/go/analysis/singlechecker.Main, a function might need to call os.Exit/log.Fatal, but want to flush any coverage reports in progress before doing so.

This bug proposes providing a mechanism to flush out the coverage report, so that if there's one in progress, it can be flushed out.

[mvdan]

/cc @alandonovan @rogpeppe @ianlancetaylor @jayconrod

This seems like a clearly good thing to me - are there any disadvantages? I do wonder how this flushing mechanism would work, though, unless cmd/cover gets special treatment from the os or runtime packages.

If we can more or less agree that this should happen, it would be great to get it into 1.13 and close all the related os.Exit issues for good :)

[ianlancetaylor]

I like the idea, but what's the mechanism?

[mvdan]

Quoting Alan's comment which started this discussion:

What if there were a "cover" package in the standard library that exposed a function to flush out the coverage report, if applicable? Applications could call it prior to their final exit. It's still imperfect because you have to remember to call flush before each exit, but at least the API would then resemble the existing ones for cpu/memory/trace.

Then Roger's comment:

The companion to that would be for a running test binary to be able to request that additional coverage information be added.

So, I think a few clarifications should be made, if I'm understanding the original thread correctly:

• This would be in a new, importable package, not cmd/cover
• This wouldn't automatically work with os.Exit, unlike how deferred function works with returns
• This might require some change in the testing package, as per Roger's comment

Perhaps Alan can clarify, particularly since he didn't reply to Roger's comment.

[ianlancetaylor]

See also #30306.

[jayconrod]

The function that does this currently is coverReport in testing. So I guess we'd basically move coverage to a new package and export that? We'd need to add -coverpkg to go build, too.

What happens if coverage data is still being recorded while that function is writing data out? Is the inconsistency okay? I don't think we currently have a global lock.

[albertito]

Hi! I'm also interested on having a mechanism like this, for the same reasons (collecting coverage of binaries during integration tests, which sometimes have to exit with os.Exit(1)/log.Fatal).

Are there any news on this? What's blocking the decision?

Thanks!

[Antonboom]

+1

[gopherbot]

Change https://go.dev/cl/411907 mentions this issue: go/analysis/checker: a go/packages-based driver library