go/types: UsesCgo exposes mangled names

[heschi]

When UsesCgo is enabled, cgo symbols appear in the package as their mangled names, e.g. _CFunc_GoString. This breaks autocomplete in gopls for C symbols. Also, it exposes things that are implementation details, like the _cgo_ and __cgofn symbols.

We can try to fix this in gopls, but probably it'd be better in go/types. I'm not sure offhand how it'll work, given that each package needs its own version of "C". Maybe the package path could be rewritten to something specific?

[mdempsky]

In CL 33677, I added support for resolving C.foo as _Cprefix_foo, but otherwise left the cgo-generated symbols in place in package scope. This is adequate for mere type-checking and analysis, but evidently suboptimal for tools like gopls, which want an accurate description of identifiers declared by the package (and imported packages, like the "C" pseudo-package).

[mdempsky]

So two limitations that will need to be addressed through further cmd/cgo support, and probably can't be resolved this late in the release cycle:

1. cmd/cgo only emits Go wrapper code for C identifiers that are actually used. E.g., if we have a package that includes <string.h> and uses C.strlen, but not C.strcmp, then go/types isn't going to know the latter exists. So a completion attempt for C.str<tab> won't be able to list it.

   Getting a complete description of all C identifiers that are accessible is possible, but would be tricky and might be prohibitively slow in practice. E.g., instead of analyzing the Go code to see what identifiers are used, cgo could analyze the C preprocessor output from the preamble and just analyze every possible C identifier.

2. Conversely, cmd/cgo emits a single Go wrapper file for the entire package, whereas each file is only allowed to access C symbols that are declared in its import "C" preamble. I.e., even if one file includes <string.h> and uses C.strlen, that doesn't necessarily mean it's valid to use in every other file that imports C. But gopls will probably suggest it anyway.

[mdempsky]

@heschik provided https://golang.org/cl/234057 as a test case.

[gopherbot]

Change https://golang.org/cl/234525 mentions this issue: go/types: type-check _cgo_gotypes.go as its own Package

[mdempsky]

@heschik I've uploaded CL 234525. It passes your test case. I'd appreciate if you could test it out in the context of gopls.

My expectation is that it should mean the _Cfoo_bar identifiers are no longer exposed within the cgo-using package, and that auto-completion for names from package C should work (aside from the limitations pointed out above).

I'll give the caveat that I think this should be fine, but it's somewhat more invasive than I feel really comfortable with at this point in the release cycle. I still think it's worth testing out now though, because if this is a desirable direction to go, I think we should tweak the UsesCgo API for this release (before it's cemented in place under Go 1 compat).

[gopherbot]

Change https://golang.org/cl/234526 mentions this issue: go/types: replace Config.UsesCgo with Checker.CgoFiles

[gopherbot]

Change https://golang.org/cl/237417 mentions this issue: go/types: rename UsesCgo to go115UsesCgo

[gopherbot]

Change https://golang.org/cl/237423 mentions this issue: go/packages: move TypecheckCgo to packagesinternal

[gopherbot]

Change https://golang.org/cl/237422 mentions this issue: internal/typesinternal: remove fallback check for UsesCgo