Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: misleading compiler error #51233

Closed
virtuald opened this issue Feb 17, 2022 · 5 comments
Closed

cmd/compile: misleading compiler error #51233

virtuald opened this issue Feb 17, 2022 · 5 comments
Labels
NeedsFix release-blocker
Milestone

Comments

@virtuald
Copy link

@virtuald virtuald commented Feb 17, 2022

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 #51232 while trying to distill this, if that's helpful
@ALTree ALTree added this to the Go1.18 milestone Feb 17, 2022
@ALTree ALTree added the NeedsInvestigation label Feb 17, 2022
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 18, 2022

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 ianlancetaylor changed the title cmd/compile: type inference error (or misleading compiler error? or both?) cmd/compile: misleading compiler error Feb 18, 2022
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 18, 2022

CC @griesemer @findleyr

@virtuald
Copy link
Author

@virtuald virtuald commented Feb 18, 2022

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

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
Copy link
Contributor

@findleyr findleyr commented Feb 18, 2022

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
Copy link

@gopherbot gopherbot commented Feb 24, 2022

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

@dmitshur dmitshur added NeedsFix and removed NeedsInvestigation labels Mar 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix release-blocker
Projects
None yet
Development

No branches or pull requests

6 participants