go/types: handle "C" package differently from gc

[dvyukov]

Two programs:

package test
/**/
import "C"

package test
/**/
import _ "C"

The first one is compiled with gc compiler (in fact, it is an excerpt from runtime/cgo/cgo.go), but gotype fails on it saying:

/tmp/cgo.go:4:8: "C" imported but not used

For the second one gc fails with:

runtime/cgo/cgo.go:32:10: cannot rename import "C"

but gotype compiles it successfully.

go/types behavior should match gc behavior.

This came up during a real attempt to use go/types to parse packages that use cgo (e.g. net).

[gopherbot]

CL https://golang.org/cl/14722 mentions this issue.

[alandonovan]

BTW: A file that uses import "C" is not necessarily a well formed Go source file. Aside from the issue of the unreferenced package name, in cgo files, references to unexported package members like C.int are allowed, and calls to functions act as if overloaded to have two variants, one that returns two results, the second being the value of errno.

So from the tool designer's perspective, files that import "C" behave like a different language that requires preprocessing to create Go code.

Have you tried using the golang.org/x/tools/go/loader package? It takes care of loading a complete Go program from source. It does cgo preprocessing as needed.

[dvyukov]

Re: golang.org/x/tools/go/loader
I have not tried it, but probably it is what I am looking for. I will try.

I see that it still uses go/types from x/tools repo. I just switched to go/types from std lib, if I use loader I will have to switch back... Are there plans to switch loader (and other packages and tools) to go/types from std lib? And, well, x/tools/go/types does not have this bug fixed.

[alandonovan]

Hi Dmitry, sorry I missed your comment till now.

Are there plans to switch loader (and other packages and tools) to go/types from std lib?

Yes, we plan to switch the loader to use the standard go/types package once Go 1.6 has settled. Before then, we will copy ~every file in the tools repo and tag them go1.5 so that the tip of the tree continues to work with old and new toolchains. This has not yet happened because I have been starved of time for external Go work.

[griesemer]

@dvyukov I will probably start working on this go/tools conversion soon if @alandonovan doesn't have a chance before me.