Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
matloob opened this issue Mar 22, 2019 · 8 comments
Open

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

matloob opened this issue Mar 22, 2019 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@matloob
Copy link
Contributor

matloob commented Mar 22, 2019

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.
@matloob matloob mentioned this issue Mar 22, 2019
Closed
@ALTree ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 24, 2019
@mvdan
Copy link
Member

mvdan commented Mar 26, 2019

/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
Copy link
Contributor

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

@mvdan
Copy link
Member

mvdan commented Mar 26, 2019 •
edited

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
Copy link
Contributor

See also #30306.

@jayconrod
Copy link
Contributor

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
Copy link
Contributor

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!

@seankhliao seankhliao mentioned this issue Aug 3, 2021
Closed
@bcmills bcmills mentioned this issue Mar 2, 2022
Open
@hyangah hyangah mentioned this issue Jun 6, 2022
Open
@Antonboom

This comment was marked as duplicate.

Sign in to view
@gopherbot
Copy link

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

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
SilverRainZ pushed a commit to SilverRainZ/tools that referenced this issue Aug 24, 2022
@adonovan @SilverRainZ
go/analysis/checker: a go/packages-based driver library
a349c62 
The {single,multi}checker packages provide the main function
for a complete application, as a black box. Many users want
the ability to customize the analyzer behavior with additional
logic, as described in the attached issues.

This change creates a new package, go/analysis/checker, that
exposes an Analyze pure function---one that avoids global flags,
os.Exit, logging, profiling, and other side effects---that
runs a set of analyzers on a set of packages loaded (by the
client) using go/packages, and presents the graph of results
in a form that allows postprocessing.

This is just a sketch. API feedback welcome.

DO NOT SUBMIT

Updates golang/go#30231
Updates golang/go#30219
Updates golang/go#31007
Updates golang/go#31897
Updates golang/go#50265
Updates golang/go#53215
Updates golang/go#53336

Change-Id: I745d319a587dca506564a4624b52a7f1eb5f4751
SilverRainZ pushed a commit to SilverRainZ/tools that referenced this issue Apr 10, 2023
@adonovan @SilverRainZ
go/analysis/checker: a go/packages-based driver library
774cf27 
The {single,multi}checker packages provide the main function
for a complete application, as a black box. Many users want
the ability to customize the analyzer behavior with additional
logic, as described in the attached issues.

This change creates a new package, go/analysis/checker, that
exposes an Analyze pure function---one that avoids global flags,
os.Exit, logging, profiling, and other side effects---that
runs a set of analyzers on a set of packages loaded (by the
client) using go/packages, and presents the graph of results
in a form that allows postprocessing.

This is just a sketch. API feedback welcome.

DO NOT SUBMIT

Updates golang/go#30231
Updates golang/go#30219
Updates golang/go#31007
Updates golang/go#31897
Updates golang/go#50265
Updates golang/go#53215
Updates golang/go#53336

Change-Id: I745d319a587dca506564a4624b52a7f1eb5f4751
SilverRainZ pushed a commit to SilverRainZ/tools that referenced this issue Apr 11, 2023
@adonovan @SilverRainZ
go/analysis/checker: a go/packages-based driver library
c41b78f 
The {single,multi}checker packages provide the main function
for a complete application, as a black box. Many users want
the ability to customize the analyzer behavior with additional
logic, as described in the attached issues.

This change creates a new package, go/analysis/checker, that
exposes an Analyze pure function---one that avoids global flags,
os.Exit, logging, profiling, and other side effects---that
runs a set of analyzers on a set of packages loaded (by the
client) using go/packages, and presents the graph of results
in a form that allows postprocessing.

This is just a sketch. API feedback welcome.

DO NOT SUBMIT

Updates golang/go#30231
Updates golang/go#30219
Updates golang/go#31007
Updates golang/go#31897
Updates golang/go#50265
Updates golang/go#53215
Updates golang/go#53336

Change-Id: I745d319a587dca506564a4624b52a7f1eb5f4751
@adonovan adonovan mentioned this issue Jul 12, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Unplanned
Development

No branches or pull requests
9 participants
@albertito @jayconrod @ianlancetaylor @mvdan @ALTree @gopherbot @seankhliao @matloob @Antonboom