@AndSDev: Does clicking the "regenerate cgo definitions" button fix the problem?

@AndSDev: Does clicking the "regenerate cgo definitions" button fix the problem?

"regenerate cgo definitions" does not help.

After switching the go version, VS Code asks to update the tools (in the notification) - after the update there is a problem.
Doing "Go: Install/Update tools" manually does not solve the problem.
"Go: Install/Update tools" allows to select packages to update.
If I manually rebuild only the gopls (after switching the go version and without rebuilding everything from the notification), there will be problems.
If I manually rebuild everything without gopls (after switching the go version and without rebuilding everything from the notification) - no problem.

Can you please share your gopls logs when you see the issue? Information on how to capture them can be found here.

VSCode gopls output.txt

I too am seeing this problem (on macOS/Darwin) with gopls reporting a type mismatch for C function calls, expecting a bool return type rather than errno/error.

Go 1.17,
VSCode 1.59.0
gopls 0.7.1

Interestingly, each function that is complaining about the mismatched error type has the C interface routine defined twice, one with two return values, and one with only one return value.

If I select "Go to Definition" for C.proc_pidfdinfo called in the example above, VSCode takes me to this:

//go:cgo_unsafe_args
func _Cfunc_proc_pidfdinfo(p0 _Ctype_int, p1 _Ctype_int, p2 _Ctype_int, p3 unsafe.Pointer, p4 _Ctype_int) (r1 _Ctype_int) {
_cgo_runtime_cgocall(_cgo_577eabb07159_Cfunc_proc_pidfdinfo, uintptr(unsafe.Pointer(&p0)))
if _Cgo_always_false {
_Cgo_use(p0)
_Cgo_use(p1)
_Cgo_use(p2)
_Cgo_use(p3)
_Cgo_use(p4)
}
return
}

However, if I search in the file for proc_pidfdinfo, I also find this:

//go:cgo_import_static _cgo_577eabb07159_C2func_proc_pidfdinfo
//go:linkname __cgofn__cgo_577eabb07159_C2func_proc_pidfdinfo _cgo_577eabb07159_C2func_proc_pidfdinfo
var __cgofn__cgo_577eabb07159_C2func_proc_pidfdinfo byte
var _cgo_577eabb07159_C2func_proc_pidfdinfo = unsafe.Pointer(&__cgofn__cgo_577eabb07159_C2func_proc_pidfdinfo)

//go:cgo_unsafe_args
func _C2func_proc_pidfdinfo(p0 _Ctype_int, p1 _Ctype_int, p2 _Ctype_int, p3 unsafe.Pointer, p4 _Ctype_int) (r1 _Ctype_int, r2 error) {
errno := _cgo_runtime_cgocall(_cgo_577eabb07159_C2func_proc_pidfdinfo, uintptr(unsafe.Pointer(&p0)))
if errno != 0 { r2 = syscall.Errno(errno) }
if _Cgo_always_false {
_Cgo_use(p0)
_Cgo_use(p1)
_Cgo_use(p2)
_Cgo_use(p3)
_Cgo_use(p4)
}
return
}

I reproduce this issue on a new user (all caches are empty, clear install of go 1.17).
gopls trace with verbose flag (for empty user):
trace_verb.log

This is a regression in go/types in Go 1.17, introduced by me.

Bisected to https://golang.org/cl/282193, where at call.go:305 I checked for commaerr operands, but overlooked that the operand mode had already been set to value on line 303.

This needs to be fixed and backported to 1.17. @mdempsky might know more about the potential impact of this bug beyond gopls.

CC @griesemer

I have spotty internet right now, so might be slow to respond.

I think commaerr should only affect gopls. The UsesCgo flag isn't generally available to other go/types users yet.

I can reproduce this and have a fix. Will send out CL a bit later today.

Change https://golang.org/cl/343809 mentions this issue: go/types: don't override x.mode before using it

@gopherbot please backport to 1.17. This is a regression.

Backport issue(s) opened: #47854 (for 1.17).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

The fix that closed this issue landed into master branch, which is where Go 1.18 development is happening, so moving this issue to the Go1.18 milestone. (The 1.17 backport issue #47854 is in 1.17.1 milestone.)