cmd/cgo: compiler accepts invalid declaration of methods on aliases to C types

[eliasnaur]

This program successfully runs with Go 1.21:

$ cat cgo_methods.go
package main

/*
typedef int foo;
*/
import "C"

type foo = C.foo

func (foo) method() int { return 123 }

func main() {
	var x foo
	println(x.method()) // "123"
}
$ go run cgo_methods.go
123

I believe this program is invalid for the same reason as the program in #57926. Note that in contrast to that issue, this program uses an alias to define a method on a C type.

[ianlancetaylor]

@alandonovan pointed out this hole in the current cgo detection of methods on C types, and I said it didn't seem worth worrying about, because who would put a method on a type alias? Interesting to see that people actually do this.

If anybody sees a simple way to fix this, by all means go for it.

[adonovan]

Clearly the fix has to be done in the compiler (since it requires symbol resolution), which I think means it will generally be possible to hand-craft some valid Go source file that that spuriously triggers the error (since cgo-generated source has no special privilege). I think this means that any approach is going to be at best a heuristic and that false positives are possible. That said, false positives (artificially weird code that doesn't compile when it should) seem less important than false negatives (such as this issue).

Some clues we could use for a heuristic:

• the receiver type name is of the form _C_foo.
• the file name is of the form go-build/XX/X{64}-d.
• the file contains a Code generated by cmd/cgo comment.
• the file uses //line directives.
• the file blank-imports the unsafe package.

Some combination of these, plus a test that the error is positively produced, is probably good enough.

[ianlancetaylor]

Just a note that I don't think we really need a heuristic to detect cgo-generated code. The cmd/go tool knows when it is compiling a Go file generated by cmd/cgo, and it could pass a special option to cmd/compile indicating that. Of course other people could use -gcflags to pass the same option....

[gopherbot]

Change https://go.dev/cl/503395 mentions this issue: cmd/cgo: compiler accepts invalid declaration of methods on aliases to C types

[gopherbot]

Change https://go.dev/cl/503397 mentions this issue: cmd/go: compiler accepts invalid declaration of methods on aliases to C types

[gopherbot]

Change https://go.dev/cl/503396 mentions this issue: cmd/compile: compiler accepts invalid declaration of methods on aliases to C types

[gopherbot]

Change https://go.dev/cl/503596 mentions this issue: go/types,types: compiler should not accept invalid declaration of methods on aliases to C types

[cuiweixie]

Change https://go.dev/cl/503596 mentions this issue: go/types,types: compiler should not accept invalid declaration of methods on aliases to C types

this fix is simple enough. Is it ok? @ianlancetaylor

[cuiweixie]

@alandonovan pointed out this hole in the current cgo detection of methods on C types, and I said it didn't seem worth worrying about, because who would put a method on a type alias? Interesting to see that people actually do this.

If anybody sees a simple way to fix this, by all means go for it.

I think this condition is simple to fix this.

isCgoGeneratedFile(T.obj.Pos()) && strings.HasPrefix(T.obj.Name(), "_Ctype_") 

fix cl