x/tools/cmd/stringer: Gets confused with pointers to C.struct_xxx types.

[npat-efault]

Save this http://play.golang.org/p/7IHAOsDFqO in foo.go and say:

stringer -type MyT foo.go

Stringer will fail with:

stringer: checking package: foo.go:22:2: invalid operation: pfoo (variable of type *invalid type) has no field or method i

Stringer works ok with this, though: http://play.golang.org/p/uIrtOCI59N

Another similar program that triggers the same behavior (stringer failure) is this: http://play.golang.org/p/P2t3O0zONt

[dmitshur]

Your program uses cgo. I wasn't sure if stringer officially supported use of cgo or not.

I looked at the source code and I didn't see any "TODO" or similar mentions regarding importing package "C", so it seems it might be supported. The .go files that import "C" are indeed processed (e.g., see here), but that's the only special thing being done.

I guess my point is that it should first be confirmed that the tool is meant to support cgo at this time. If so, this is likely a problem with it (since I imagine it's a situation that's less common and therefore more poorly tested).

[adonovan]

stringer doesn't support cgo. It makes the simplifying assumptions that the initial package consists only of Go source files and that dependencies can be loaded from compiler export data (e.g. $GOROOT/pkg/$GOOS_$GOARCH/fmt.a).

Background:

This issue is more or less a duplicate of "stringer: can't find packages" (#10249). Josh closed it and filed the broader issue "go/loader: importers should just work" (#10276). I closed that after some changes to go/loader; in passing, I created a CL to make stringer use go/loader (https://go-review.googlesource.com/#/c/8561/) but it was rejected by Rob "until go/loader is tidied up". go/loader could use more tidying up, though I won't be able to get to this for a while. In the meantime, stringer still has this bug.