go-fuzz-build: add module support

[iwasaki-kenta]

Is there any support to allow for go-fuzz-build to checkout and build a custom branch of a repository?

Additionally, is there any support to specify a directory to go-fuzz-build comprising of a Go module?

The reason I'm trying to checkout and build a custom branch is that go-fuzz-build seems to only work when executed within GOROOT, though my project makes use of Go modules extensively right now.

[josharian]

Is there any support to allow for go-fuzz-build to checkout and build a custom branch of a repository?

No. This is the same as regular go build. I’m afraid you’ll have to write a script to do that. Or you might want to look at fuzzbuzz.io. (No affiliation.)

Additionally, is there any support to specify a directory to go-fuzz-build comprising of a Go module?

go-fuzz does not yet support modules; my apologies.

go-fuzz-build seems to only work when executed within GOROOT

I’m not sure offhand why that would work, but if you’re using modules, that does explain why go-fuzz-build isn’t working for you in normal circumstances.

[iwasaki-kenta]

Is there any support to allow for go-fuzz-build to checkout and build a custom branch of a repository?

No. This is the same as regular go build. I’m afraid you’ll have to write a script to do that. Or you might want to look at fuzzbuzz.io. (No affiliation.)

Additionally, is there any support to specify a directory to go-fuzz-build comprising of a Go module?

go-fuzz does not yet support modules; my apologies.

go-fuzz-build seems to only work when executed within GOROOT

I’m not sure offhand why that would work, but if you’re using modules, that does explain why go-fuzz-build isn’t working for you in normal circumstances.

Pardon for the late reply; would the project be open to contributions right now for supporting projects that use Go modules?

[dvyukov]

How complex is that approximately?
I can't think of any objections and I guess we should support modules. The only problem that I can think of is that we will re-implement another large, non-trivial, fragile part of go tool. Can we reuse bulk of the logic from go tool? @josharian do you know if that packages package support modules?

[iwasaki-kenta]

How complex is that approximately?
I can't think of any objections and I guess we should support modules. The only problem that I can think of is that we will re-implement another large, non-trivial, fragile part of go tool. Can we reuse bulk of the logic from go tool? @josharian do you know if that packages package support modules?

From a brief skim of how go-fuzz-build works currently (type-checking a provided package directory, and afterwards packaging up stdlibs + the source code), it seems that the /x/tools/go/packages pkg is outdated and presently doesn't support modules.

As an alternative, it is possible to use the type-checking and package import resolver straight from the current Go standard library which also resolves import paths to packages that use Go modules.

The complexity would be moderate, as the APIs are mostly the same.

For resolving build src paths: https://golang.org/pkg/go/build/
For type-checking pkgs: https://golang.org/pkg/go/types/

For functions of interest:

Resolving build paths: https://golang.org/pkg/go/build/#Context.Import
Type-checking: https://golang.org/pkg/go/types/#Config.Check

Though, if there are reasons as to why /x/tools/go/packages is used instead, would love to know.

[josharian]

Package go/build is deprecated. x/tools/go/packages is very much the preferred path going forward, and it definitely supports modules. In fact, module support was a major factor in the decision to write go/packages; it was not reasonable to retrofit it into go/build.

I suspect (but have not tried) that all that is required to add module support is to (a) copy go.mod if present while copying packages and (b) synthesize a go.mod alongside our synthesized package main.

I intend to work on module support at some point, but it isn't high on my list at the moment. I suppose it should be higher. I'd be happy to review a PR.

[dvyukov]

From you said it seems that the modules support will be moderate amount of code and no significant duplication with std lib. Modules support is welcome. @iwasaki-kenta go ahead.

[josharian]

I’m going to close this as a duplicate of #195.