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/go2go: "receiver type inference failed" panic on invalid type #40056

Closed
rogpeppe opened this issue Jul 5, 2020 · 4 comments
Closed

cmd/go2go: "receiver type inference failed" panic on invalid type #40056

rogpeppe opened this issue Jul 5, 2020 · 4 comments
Assignees
Milestone

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Jul 5, 2020

commit 34f7622

The following program panics instead of producing a type-check error.

package main

func main() {
	NewS().M()
}

type S struct {}

func NewS(type T)() *S {
	return nil
}

func (c *S(T)) M() {}

The panic traceback is:

panic: internal error: receiver type parameter inference failed [recovered]
	panic: internal error: receiver type parameter inference failed

goroutine 1 [running]:
go/types.(*Checker).handleBailout(0xc00007c7e0, 0xc0000cbbe0)
	/usr/local/go-faketime/src/go/types/check.go:251 +0x98
panic(0x6498a0, 0x6db6e0)
	/usr/local/go-faketime/src/runtime/panic.go:969 +0x175
go/types.(*Checker).selector(0xc00007c7e0, 0xc000072740, 0xc00000c240)
	/usr/local/go-faketime/src/go/types/call.go:534 +0x25b7
go/types.(*Checker).exprInternal(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1320 +0x29cc
go/types.(*Checker).rawExpr(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).exprOrType(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240)
	/usr/local/go-faketime/src/go/types/expr.go:1717 +0x55
go/types.(*Checker).call(0xc00007c7e0, 0xc000072740, 0xc0000722c0, 0x0)
	/usr/local/go-faketime/src/go/types/call.go:17 +0x69
go/types.(*Checker).exprInternal(0xc00007c7e0, 0xc000072740, 0x6e32a0, 0xc0000722c0, 0x0, 0x0, 0x38)
	/usr/local/go-faketime/src/go/types/expr.go:1569 +0x1dd0
go/types.(*Checker).rawExpr(0xc00007c7e0, 0xc000072740, 0x6e32a0, 0xc0000722c0, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).stmt(0xc00007c7e0, 0x0, 0x6e3520, 0xc00001c500)
	/usr/local/go-faketime/src/go/types/stmt.go:330 +0x3e78
go/types.(*Checker).stmtList(0xc00007c7e0, 0x0, 0xc00001c510, 0x1, 0x1)
	/usr/local/go-faketime/src/go/types/stmt.go:125 +0xd1
go/types.(*Checker).funcBody(0xc00007c7e0, 0xc00004a4e0, 0xc00001a3e8, 0x4, 0xc00004a660, 0xc000010b70, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/stmt.go:42 +0x257
go/types.(*Checker).funcDecl.func1()
	/usr/local/go-faketime/src/go/types/decl.go:790 +0x67
go/types.(*Checker).processDelayed(0xc00007c7e0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:315 +0x3e
go/types.(*Checker).checkFiles(0xc00007c7e0, 0xc00003dcb8, 0x1, 0x1, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:283 +0x145
go/types.(*Checker).Files(...)
	/usr/local/go-faketime/src/go/types/check.go:256
go/types.(*Config).Check(0xc0000724c0, 0xc00001a3e0, 0x4, 0xc000072240, 0xc00003dcb8, 0x1, 0x1, 0xc000055360, 0x0, 0x4b702f, ...)
	/usr/local/go-faketime/src/go/types/api.go:387 +0x188
go/go2go.RewriteBuffer(0xc00004a3c0, 0x7ffc90c44dec, 0x1e, 0xc0000ba000, 0x7b, 0x27b, 0x0, 0xc000010a50, 0xc000010a20, 0xc0000109f0, ...)
	/usr/local/go-faketime/src/go/go2go/go2go.go:137 +0x24f
main.translateFile(0xc00004a3c0, 0x7ffc90c44dec, 0x1e)
	/usr/local/go-faketime/src/cmd/go2go/translate.go:26 +0xa9
main.main()
	/usr/local/go-faketime/src/cmd/go2go/main.go:65 +0x2f6
@thepudds
Copy link

@thepudds thepudds commented Jul 5, 2020

Possibly related to #39758 (comment).

That one used to crash in a different spot, but in the current playground, that one and the example from this issue both panic in go/types.(*Checker).selector at go/types/call.go:534 with what looks to be the same 4-5 calls on the callstack leading up to that.

However, perhaps different underlying issues...

@rogpeppe
Copy link
Contributor Author

@rogpeppe rogpeppe commented Jul 5, 2020

Yes, I'm not sure. I raised a different issue because this one didn't involve embedding.

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 7, 2020

Change https://golang.org/cl/241130 mentions this issue: [dev.go2go] go/types: don't panic if receiver type arguments cannot be inferred

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jul 7, 2020

Fixed on dev.go2go.

@griesemer griesemer closed this Jul 7, 2020
gopherbot pushed a commit that referenced this issue Jul 7, 2020
…e inferred

This can happen due to earlier errors. This change avoids the panic
but reports a follow-up error. Not ideal, but good enough for now.

Fixes #40056.

Change-Id: I500d4fc2b058cdc70f28883ff8d004df4b43fe4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/241130
Reviewed-by: Robert Griesemer <gri@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.