zimmski/go-mutesting

"undeclared name" while loading package

gregLibert opened this issue · 5 comments

gregLibert commented

Hi,

I've got an error while executing the following command:

> go-mutesting --verbose --debug .
Enable mutator "branch/case"
Enable mutator "branch/else"
Enable mutator "branch/if"
Enable mutator "expression/comparison"
Enable mutator "expression/remove"
Enable mutator "statement/remove"
Save mutations into "/tmp/go-mutesting-389248154"
Mutate "config.go"
/tmp/sql/config.go:23:10: undeclared name: newConfigError
/tmp/sql/config.go:27:10: undeclared name: newConfigError
/tmp/sql/config.go:31:10: undeclared name: newConfigError
Could not load package of file "config.go": couldn't load packages due to errors: /tmp/sql

newConfigError is in my scenario a function defined in the same package, but in another file.

Playing with the code, I found out here that you are only loading one file if importPath is equal to ".".
As only one file is loaded (instead of all go files in the module), every entities not present in the same file raised exception.

Replacing conf.CreateFromFilenames(dir, fileAbs) with conf.Import(buildPkg.ImportPath) in parse.go solved my problem, but I'm not sure that the best thing to do as I don't really know the inner logic...

apgrucza commented

I had the same problem. After moving my Go code into the proper location (a directory under $GOPATH/src), the problem went away.

smoyer64 commented

After moving my Go code into the proper location

That's not necessarily the proper location for code that's versioned using Go modules. I'm having this problem in libraries that are built this way.

apgrucza commented

Yes, it does seem that go-mutesting doesn't really support projects with Go modules and this needs to be fixed.

The only way I've found to work around this problem is to copy the Go code into a directory under $GOPATH/src, and then run (in the project directory under $GOPATH/src):

GO111MODULE=off go get -t -v .
GO111MODULE=on go-mutesting .

When creating mutants, go-mutesting temporarily modifies the source code in-place, so copying the source code to another directory has the added benefit of ensuring that those mutations are not kept if go-mutesting terminates prematurely.

smoyer64 commented

It seems like it would be wise to copy the code to a temporary folder before creating the mutants ... should this be another issue?

benmoss commented

this was fixed for me by using the fork from #77

  • ❤️1