Comments (13)
looking into this a bit, it's because of the way gocov instruments the package then forks to go test. The instrumented package will take precidence in $GOPATH, but will fail if the package came from $GOROOT. I think to fix this properly would require a much tighter integration with go test, probably bringing it in process with gocov.
from gocov.
Alternatively, GOROOT would have to be faked too. i.e. just like's done for the temporary GOPATH, create a temporary GOROOT, symlink everything, and instrument the GOROOT packages in there. Might want to exclude stdlib packages by default to avoid rebuilding the world all the time.
I haven't tried this, but it should work I think?
from gocov.
Roger Peppe suggested placing the annotated pkg in a different path, ie fmt -> cov/fmt, which won't be trumped by GOROOT. There may be some complications with recursive annotations, but they are probably solvable.
On 11/07/2012, at 22:53, Andrew [email protected] wrote:
Alternatively, GOROOT would have to be faked too. i.e. just like's done for the temporary GOPATH, create a temporary GOROOT, symlink everything, and instrument the GOROOT packages in there. Might want to exclude stdlib packages by default to avoid rebuilding the world all the time.
I haven't tried this, but it should work I think?
Reply to this email directly or view it on GitHub:
#2 (comment)
from gocov.
I like it.
from gocov.
So I went ahead and tested both approaches. The symlinked GOROOT approach seemed simple at first, until I realised that the added imports of "github.com/axw/gocov" to each instrumented package would introduce an import loop.
The approach suggested by Roger is a little more involved, but looks like it'll work. If I have some more time over the weekend I'll clean it up and commit.
from gocov.
Awesome. Looking forward to seeing your results. Being about to do
coverage checks on the std library would be a significant milestone.
On Fri, Jul 13, 2012 at 11:55 PM, Andrew Wilkins
[email protected]
wrote:
So I went ahead and tested both approaches. The symlinked GOROOT approach seemed simple at first, until I realised that the added imports of "github.com/axw/gocov" to each instrumented package would introduce an import loop.
The approach suggested by Roger is a little more involved, but looks like it'll work. If I have some more time over the weekend I'll clean it up and commit.
Reply to this email directly or view it on GitHub:
#2 (comment)
from gocov.
I've committed the change. You can now pass "-exclude-goroot=false" to gocov test, and it'll instrument GOROOT packages. They add enough overhead that they're disabled by default. Unfortunately, there are some packages that are always disabled: reflect, runtime, os, sync, syscall, time, testing
The problem is that the package names get changed, which changes functions' symbol names. This causes a problem in mixed Go/(non-cgo) C packages.
Also, if you happen to see nil-pointer dereference panics in gocov.Statement.At(), then it may be due to a compiler bug (waiting on confirmation): http://code.google.com/p/go/issues/detail?id=3824
from gocov.
Seems this doesn't work properly, at least for net/http. I'm not sure what exactly is causing the errors, but I think it's due to having multiple instances of the same package (e.g. because gocov imports io, we end up with an instrumented and an uninstrumented version of io.)
I have an idea for how to fix the GOROOT cycle problem, but it's horrible: remove all Go imports from gocov, and change them to C functions which refer to the external packages's function symbols explicitly, and force those packages to be loaded with a dummy package. The gocov code would then need to check for and ignore recursive calls.
... or do it all with cgo? blurgh
from gocov.
Fixed in (pending) pull request #16.
from gocov.
Fixed.
from gocov.
Oops, should mention: gocov still can't instrument the following packages: sync, sync/atomic, syscall and runtime. This is because any instrumented package must import gocov, and gocov imports those listed packages, so this would introduce a cycle. This is unlikely to ever change.
from gocov.
I think that is a reasonable limitation. With the exception of
sync{,/atomic} they don't have good tests coverage anyway.
On Tue, Jan 8, 2013 at 12:28 PM, Andrew Wilkins [email protected]:
Oops, should mention: gocov still can't instrument the following packages:
sync, sync/atomic, syscall and runtime. This is because any instrumented
package must import gocov, and gocov imports those listed packages, so this
would introduce a cycle. This is unlikely to ever change.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-11980587.
from gocov.
Batshit crazy idea, for posterity: since everything requires runtime, when instrumenting, copy the gocov sources into the runtime package and have everything point to those functions instead. Then everything can be instrumented.
from gocov.
Related Issues (20)
- [Question] Can i use gocov to get code coverage report for a go application if my tests are written in another framework using python HOT 3
- Does gocov not support generics in Go version 1.20? HOT 1
- Does gocov currently support generics,expected '(', found '[' (and 5 more errors)
- When the file size of coverage is large (420KB), generating json is very slow, taking several hours
- how to confirm the supported GO version of gocov
- gocov's result is different from go test HOT 1
- If a package has no test files, the lines in that package are not added to the total line count. HOT 10
- Pass arguments to go list HOT 4
- please tag a version, to make go modules usage easier HOT 2
- gocov: gocov report print total coverage NaN% when totalReached and totalStatements are zero
- gocov does not pass -tags parameter HOT 1
- What is the difference to the go standard tools?
- gocov failed when trying on file that has a formatting directive
- 按照指示安装不了,有什么国内的镜像地址吗 HOT 1
- go get doesn't install HOT 2
- the code source default is $GOROOT. whether the code source path can be specified by the user when using gocov convert? HOT 3
- Unable to use go install HOT 2
- gocov with go1.18 generics HOT 3
- [question] Is it possible to exclude a method from code coverage? HOT 1
- gocov with coverprofile raise error, the file path contains duplicate parts HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gocov.