mvdan/goreduce

goreduce can't find imported modules?

dkegel-fastly opened this issue · 6 comments

I have a directory full of go that builds fine with regular go:

$ go build

but fails to build with goreduce:

$ goreduce -match=xxxxnomatchxxx .
error does not match:
cmdexe.go:8:2: no required module provides package github.com/gobwas/glob; to add it:
	go get github.com/gobwas/glob

I worked around this by either commenting out the use of the unfound module, or bodily importing it into the source tree (go mod vendor wasn't enough). Evidently not all modules are affected, not sure what the deal is.

mvdan commented

Does go mod tidy change go.mod in a way that makes goreduce happy?

If not, then maybe our code is too old to properly support modules nowadays. https://pkg.go.dev/golang.org/x/tools/go/packages has become the standard for loading a package in the last few years, after I wrote that code.

Alas, no, go mod tidy doesn't seem to help.

I'm hitting this as well, unfortunately.

@mvdan any pointers on how to update the code to use x/tools/go/packages? I poked at it a bit, but the needed changes weren't immediately obvious to me.

mvdan commented

Right now the code assumes that it only needs to reduce one directory of Go files (a package):

pkgs, err := parser.ParseDir(r.fset, dir, nil, parser.ParseComments)

and it manually re-runs the typechecker after each successful change:

r.tconf.Check(r.tdir, r.fset, r.files, r.info)

We could replace both of those with complete new calls to packages.Load with NeedSyntax and NeedTypes, but that would be very expensive. Right now, our incremental typechecking reuses work, I think.

I think the best option would be to replace importer.Default with a custom importer fed by go list -json, which does know how to locate module dependencies. I did just that in a different project:

https://github.com/burrowers/garble/blob/d342de40990fafc6ab5d4542cf67b7abd9fe1d8a/main.go#L142-L151

Still, that isn't a trivial change to make either.

I know it can be frustrating that the tool doesn't work with modules right now. The truth is that I haven't actively worked on this project in a while, as I've found other open source efforts more interesting and fruitful :) That doesn't mean the project is dead or useless - it's not archived after all. But it's certainly not in a good working state in general right now. I'd be happy to move the repository to a github org and give others write access if someone has the time and energy to improve the tool.