x/tools/cmd/stringer: can't find packages

[randall77]

I'm having a problem using stringer with go generate. It reports errors because it can't find packages that I think it should be able to find. go build has no trouble finding them.

a.go, in directory $GOPATH/src/a:

package a

import "a/b"

type A int

const (
Aone A = 1
Atwo = 2
Athree = 3
)

//go:generate stringer -type=A

func a() {
b.B()
}

b.go, in directory $GOPATH/src/a/b:

package b

func B() {
}

In $GOPATH/src/a, this happens:

go generate
stringer: checking package: a.go:3:8: could not import a/b (can't find import: a/b)
a.go:13: running "stringer": exit status 1

Running go build instead of go generate works fine.

[minux]

Have you tried "go install a/b" before running stringer?

[randall77]

Ok, that works. Why?

[robpike]

Stringer packages to be installed so it can parse and type check the files it's reading.

[josharian]

Ok, that works. Why?

stringer uses go/types, which uses go/loader to find packages. There are multiple strategies for finding packages available. Stringer uses gcimporter, which parses gc's object files. If the package has not been installed, the object files are not available to parse.

[randall77]

So this should be documented somewhere, perhaps at https://godoc.org/golang.org/x/tools/cmd/stringer
Confused the hell out of me.

[robpike]

It's not a property of stringer per se. You can't build or parse (actually type check) a package without building (or parsing) its dependencies first. Any tool that looks at types has the same property.

It's the nature of the work.

[randall77]

So shouldn't stringer build its dependencies if they haven't been built yet? Or at least parse them if it can't find a built object file? Or give me a better error message than "could not import a/b (can't find import: a/b)", like "could not import a/b (it must be built first)"?

[josharian]

@randall77 I agree entirely, but this is a broader problem than just stringer. Filed #10276 for this.

[alandonovan]

For the record:

This CL https://go-review.googlesource.com/#/c/8561/ changes stringer to use go/loader, which loads the entire program from source code, so it gets the correct result no matter what compiler you use or how fresh your .a cache is. The change has been mothballed pending a clean-up of the go/loader API (some of which has already happened).

[szabba]

What's the status on this? Will this not be implemented, or will this be addressed somewhere else (the Go gerrit seems to suggest this was abandoned altogether)?