I'm not sure how "go run" would communicate to the subprocess that it should collect coverage. "go test" does so by passing a command-line flag, no?

This would be really nice. Here's one example of a test that builds a binary, then runs it to test the main function: app_test.go (and the associated testutil)

It would be great to have that considered for code/test coverage.

Need to think more but I don't really understand what this would mean.

I'm not sure how "go run" would communicate to the subprocess that it should collect coverage. "go test" does so by passing a command-line flag, no?

Not quite. Passing -cover to go test enables rewriting of source code. See https://blog.golang.org/cover for more info. go run -cover can do the same.

I uploaded a fix for discussion here: https://go-review.googlesource.com/42096.
cc @rsc

CL https://golang.org/cl/42096 mentions this issue.

I tend to agree that we want to keep go run limited in its scope.

But there is no 'go build -cover' so at the very least that would need to happen first. If that did happen, then go run -cover might fall out for free. That said, I'm not sure go build -cover should happen. Coverage is fairly tied to testing. If you did -cover outside of tests you'd need to recreate the testing package support that exports the coverage info.

Uh. Then maybe testing support for coverage info should be extracted to some package, /x/ maybe? Right now it's private, and existing solution is too fragile.

@AlekSi Whatever you suggest, that should probably be in a different issue. We are still unlikely to add go run -cover. Thanks.