cmd/compile: misleading compiler error

[virtuald]

What version of Go are you using (go version)?

$ go version
go version devel go1.18-eaf0405 Wed Feb 16 21:34:51 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

https://go.dev/play/p/PzbJGM7V9dn?v=gotip

 package main
 
 type RC[RG any] interface {
 	~[]RG
 }
 
 type Fn[RCT RC[RG], RG any] func(RCT)
 
 type FFn[RCT RC[RG], RG any] func() Fn[RCT]
 
 type F[RCT RC[RG], RG any] interface {
 	Fn() Fn[RCT]
 }
 
 type concreteF[RCT RC[RG], RG any] struct {
- 	makeFn FFn[RCT]
+ 	makeFn FFn[RCT, RG]
 }
 
 func (c *concreteF[RCT, RG]) Fn() Fn[RCT] {
 	return c.makeFn()
 }
 
 func main() {}

What did you expect to see?

Nothing.

What did you see instead?

./prog.go:20:9: invalid operation: cannot call non-function c.makeFn (variable with invalid type)

If I change the line from the red version to the green version (adding the explicit type), then the compilation error disappears. I expected the compiler to figure out RG since it was part of the definition of RCT.

If type inference isn't able to figure this out, then it would be good to fix the compiler error to be less confusing. makeFn is a function, the error is actually that the compiler can't infer how to instantiate it.

Notes

• This isn't actually quite the error I originally ran into, but it's similar enough that it's likely related
• I ran into cmd/compile: internal compiler error: invalid memory address or nil pointer dereference #51232 while trying to distill this, if that's helpful

[ianlancetaylor]

There is no form of type inference that will figure out the additional type argument for FFn. This code is not valid according to the current rules.

That said I agree that the error message is pretty bad.

[ianlancetaylor]

CC @griesemer @findleyr

[virtuald]

@ianlancetaylor something that's a bit confusing about this is that it only seems to be a compile error when I actually call makeFn. See the following two examples that do not result in compiler errors with the same struct definition:

• Not using it at all
• Returning makeFn is fine

Is this expected behavior? It's a bit weird to me that changing something outside of the struct definition can magically cause a compilation error in a struct definition that hasn't changed.

[findleyr]

I just looked at this briefly. It looks like the bug is in the order of instantiation: where we try to substitute in the underlying of FFn[RCT] before its type arguments are inferred.

The error is not coming from type inference, which is why it only occurs if the field is used.

[gopherbot]

Change https://go.dev/cl/387918 mentions this issue: types2: delay receiver type validation