search

mvdan / goreduce

Reduce Go programs
BSD 3-Clause "New" or "Revised" License
216 stars 7 forks source link

goreduce can't find imported modules? #27

Open dkegel-fastly opened 3 years ago

dkegel-fastly commented 3 years ago

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
dkegel-fastly commented 3 years ago

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 3 years ago

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.

dkegel-fastly commented 3 years ago

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

mark-pictor-csec commented 2 years ago

I'm hitting this as well, unfortunately.

mark-pictor-csec commented 2 years ago

@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 2 years ago

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

https://github.com/mvdan/goreduce/blob/930bfd654df05eb59c7c9583dc41f6726f5d56be/reduce.go#L92

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

https://github.com/mvdan/goreduce/blob/930bfd654df05eb59c7c9583dc41f6726f5d56be/reduce.go#L250

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.