Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dvyukov opened this issue Sep 17, 2015 · 5 comments
Closed

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

dvyukov opened this issue Sep 17, 2015 · 5 comments
Assignees
Milestone

Comments

@dvyukov
Copy link
Member

@dvyukov dvyukov commented Sep 17, 2015

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).

@dvyukov dvyukov added this to the Go1.6 milestone Sep 17, 2015
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2015

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

Loading

@alandonovan
Copy link
Contributor

@alandonovan alandonovan commented Sep 18, 2015

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.

Loading

@dvyukov
Copy link
Member Author

@dvyukov dvyukov commented Sep 19, 2015

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.

Loading

@alandonovan
Copy link
Contributor

@alandonovan alandonovan commented Nov 25, 2015

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.

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 25, 2015

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

Loading

@golang golang locked and limited conversation to collaborators Nov 27, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants