@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.

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.

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....

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

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

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

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

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

@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

Well spotted! I didn't realize the compiler already had an official heuristic for isCgoGeneratedFile. Let's use that.

@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

@ianlancetaylor is this condition ok,isCgoGeneratedFile(T.obj.Pos()) && strings.HasPrefix(T.obj.Name(), "Ctype") ?

@cuiweixie Yes. Thanks.

This is another very commonly used package that will no longer compile using Go 1.21: bugst/go-serial#162

This is another very commonly used package that will no longer compile using Go 1.21: bugst/go-serial#162

At the risk of sounding flippant, I might rephrase that as "another package that got away with invalid code". Fortunately the problematic cases all seem to be internal so it should be an easy fix.

@adonovan indeed, I submitted a PR to that repo with fix.