Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/cmd/stringer: Gets confused with pointers to C.struct_xxx types. #13123
Save this http://play.golang.org/p/7IHAOsDFqO in
Stringer will fail with:
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
Your program uses cgo. I wasn't sure if
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).
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).
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.