x/tools/gopls: check CGO_ENABLED when symbol is undefined because of implicit build constraint #70863
Description
Proposal Details
CGO docs says the import "C" implies the "cgo" build constraint:
The go tool will set the build constraint "cgo" if cgo is enabled. The special import "C" implies the "cgo" build constraint, as though the file also said "//go:build cgo".
Hence, when the code is arranged as this, the go tool reports ./main.go:8:6: undefined: sub.API for the following project in txtar format when I run CGO_ENABLED=0 go build. I want to propose this because when a 3rd library uses import "C" in a go file with several package level functions and my local CGO_ENABLED=0, the build fails without any useful error hint.
The gopls emits the same error hint when the CGO_ENABLED=0.
I proposed the gopls to check the files with import "C" additionally after gopls found an undefined error from go tool when CGO is disabled. It should give an hint that "undefined: sub.API. CGO is disabled so symbols inside file sub.go are excluded" if we can find the symbol API inside file sub.go.
This may apply to the undefined symbols which exist in the certain build contraints under the same package. But I would like to narrow the proposal down to CGO only because CGO build constraint is implicit convention but the others are explicit. Moreover, the import "C" affects the other functions inside the same file as build contraint is file level.
-- go.mod --
module github.com/xieyuschen/example
go 1.21
-- main.go --
package main
import (
"github.com/xieyuschen/example/sub"
)
func main() {
sub.API()
}
-- sub/sub.go --
package sub
// int fortytwo()
// {
// return 42;
// }
import "C"
func CAPI() {
C.fortytwo()
}
func API() {
C.fortytwo()
}
-- sub/sub2.go --
package sub
// this file is used to make a go file available for package sub