x/tools/gopls: check CGO_ENABLED when symbol is undefined because of implicit build constraint

[xieyuschen]

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

[gabyhelp]

Related Issues

• cmd/go: give a better error message when building Go package with CGO_ENABLED=0 #24068
• go/build: imports from cgo files included in Imports when CGO_ENABLED=0 #35946 (closed)
• cmd/go: with -compiler=gccgo should build C files even if CGO_ENABLED=0 #41758
• x/tools/gopls: improve support for users of cgo packages #35720 (closed)
• `go build` produces bad error message when CGO_ENABLED=0 but need to build using cgo #69288 (closed)
• x/tools/gopls: improve support for authoring cgo packages #35721
• cmd/go: importing "C" with CGO disabled should be an error #12860 (closed)
• x/tools/gopls: improve cgo support #32898 (closed)

Related Code Changes

• cmd/cgo: clarify implicit "cgo" build constraint
• go/build: fail to build "plugin" if CGO_ENABLED=0

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

I don't see a reason for this to be a proposal. Taking it out of the proposal process.