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

Jump to bottom

cmd/compile: gotip internal compiler error: shape types have no methods .shape.string_0 #49309

Closed
inso opened this issue Nov 3, 2021 · 6 comments
Closed

cmd/compile: gotip internal compiler error: shape types have no methods .shape.string_0 #49309

inso opened this issue Nov 3, 2021 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@inso
Copy link

inso commented Nov 3, 2021

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

$ gotip version
go version devel go1.18-519c0a2 Wed Nov 3 05:00:00 2021 +0000 linux/amd64

What did you do?

$ cat issue.go 
package main

func test[T any](f func (c T)) {
	var r T

	f(r)
}

func test2(a ...interface{}) {
}

func main() {
	test(func(c string) { test2(c) })
}

$ gotip build issue.go

What did you expect to see?

Successful compilation

What did you see instead?

# command-line-arguments
./issue.go:13:6: internal compiler error: shape types have no methods .shape.string_0

goroutine 1 [running]:
runtime/debug.Stack()
	/home/inso/sdk/gotip/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0xce818?, 0xc0?}, {0xd2377b, 0x1f}, {0xc0000ce808, 0x1, 0x1})
	/home/inso/sdk/gotip/src/cmd/compile/internal/base/print.go:227 +0x1ca
cmd/compile/internal/base.Fatalf(...)
	/home/inso/sdk/gotip/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/reflectdata.MarkTypeUsedInInterface(0xc0003dc690, 0xc0000f5380)
	/home/inso/sdk/gotip/src/cmd/compile/internal/reflectdata/reflect.go:1979 +0x6f
cmd/compile/internal/walk.walkConvInterface(0xc0003db900, 0xc0000ceea0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/convert.go:49 +0x107
cmd/compile/internal/walk.walkExpr1({0xe81e50, 0xc0003db900}, 0xc0003db900?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:211 +0x57f
cmd/compile/internal/walk.walkExpr({0xe81e50, 0xc0003db900}, 0xc0000ceea0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:55 +0x428
cmd/compile/internal/walk.walkAssign(0xc0000ceea0, {0xe814f0, 0xc0005605a0?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/assign.go:72 +0x9dc
cmd/compile/internal/walk.walkExpr1({0xe814f0, 0xc0005605a0}, 0xc0005605a0?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:179 +0x43f
cmd/compile/internal/walk.walkExpr({0xe814f0, 0xc0005605a0}, 0xc0000ceea0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:55 +0x428
cmd/compile/internal/walk.walkStmt({0xe814f0, 0xc0005605a0?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/stmt.go:57 +0x7da
cmd/compile/internal/walk.walkStmtList(...)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/stmt.go:175
cmd/compile/internal/walk.walkStmt({0xe81748, 0xc000568200?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/stmt.go:98 +0xe3c
cmd/compile/internal/walk.slicelit(0x0, 0xc0000f4900, {0xe82eb8?, 0xc0003e25b0}, 0xc0000cf6d8)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/complit.go:405 +0xc6d
cmd/compile/internal/walk.anylit({0xe81cc0, 0xc0000f4900}, {0xe82eb8?, 0xc0003e25b0}, 0xc000546680?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/complit.go:592 +0x4c5
cmd/compile/internal/walk.oaslit(0xc000560370, 0xc0003e25b0?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/complit.go:635 +0x198
cmd/compile/internal/walk.walkAssign(0xc0000cf6d8, {0xe814f0, 0xc000560370?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/assign.go:57 +0x5eb
cmd/compile/internal/walk.walkExpr1({0xe814f0, 0xc000560370}, 0xc000560370?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:179 +0x43f
cmd/compile/internal/walk.walkExpr({0xe814f0, 0xc000560370}, 0xc0000cf6d8)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:55 +0x428
cmd/compile/internal/walk.appendWalkStmt(0xc0000cf6d8, {0xe814f0, 0xc000560370})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/walk.go:256 +0x65
cmd/compile/internal/walk.ascompatee(0x16, {0xc00009f1f0?, 0x1, 0x1?}, {0xc00009f1d0, 0x1, 0x7f3a0419c600?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/assign.go:372 +0x6eb
cmd/compile/internal/walk.walkAssignList(0xc0000cfa70, 0xc0003ce720)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/assign.go:146 +0x12f
cmd/compile/internal/walk.walkExpr1({0xe81360, 0xc0003ce720}, 0xc0003ce720?)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:183 +0x325
cmd/compile/internal/walk.walkExpr({0xe81360, 0xc0003ce720}, 0xc0000cfa70)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/expr.go:55 +0x428
cmd/compile/internal/walk.walkStmt({0xe81360, 0xc0003ce720?})
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/stmt.go:57 +0x7da
cmd/compile/internal/walk.walkStmtList(...)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/stmt.go:175
cmd/compile/internal/walk.Walk(0xc0003c91e0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/walk/walk.go:43 +0x151
cmd/compile/internal/gc.prepareFunc(0xc0003c91e0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/gc/compile.go:92 +0x6d
cmd/compile/internal/gc.enqueueFunc(0xc0003c91e0)
	/home/inso/sdk/gotip/src/cmd/compile/internal/gc/compile.go:66 +0x2fd
cmd/compile/internal/gc.Main(0xd3da98)
	/home/inso/sdk/gotip/src/cmd/compile/internal/gc/main.go:309 +0xf97
main.main()
	/home/inso/sdk/gotip/src/cmd/compile/main.go:55 +0xdd
@cuonglm cuonglm added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 3, 2021
@cuonglm cuonglm added this to the Go1.18 milestone Nov 3, 2021
@cuonglm
Copy link
Member

cuonglm commented Nov 3, 2021

Sounds like the problem dues to inlining. We implicitly generate OCONVIFACE from .shape.string_0 to interface{}.

cc @randall77 @danscales

@danscales
Copy link
Contributor

danscales commented Nov 3, 2021 •
edited

Yes, this one is tricky. Easier to discuss if we use this example with no anonymous func and better names:

package main

func genfunc[T any](f func(c T)) {
	var r T

	f(r)
}

func myfunc(c string) {
	test2(c)
}

//go:noinline
func test2(a interface{}) {
}

func main() {
	genfunc(myfunc)
}

I guess this points out a general problem that we may reveal new CONVIFACE calls related to typeparams in a function instantiation after the fact by doing inlining. However, this can only happen if we actually pass in an inlineable function as an argument ("myfunc" here) that matches a relevant typeparam, and then can inline that function call, because we were actually able to inline the function instantiation as well.... (i.e. we were able to inline "genfunc[%2eshape.string_0]" into main, which means we are then able to inline "myfunc" as well.

Because r is "stuck" as a shape type, we need a dictionary when converting r to an empty interface in order to call test2.

We don't want to disable inlining generally in function instantiations, but maybe we can disable inlining for functions that have shape args? Still thinking about it.

@cuonglm
Copy link
Member

cuonglm commented Nov 3, 2021

We do have the .dict param as first argument of genfunc when doing inline. Can we use that?

@danscales
Copy link
Contributor

Sorry, I was a little unclear. As it stands, we want to set the dictionary format for an instantiation (what derived types are relevant, what itabs are needed) right after the stenciling . But in this case, we won't necessarily have the right dictionary entry after the inlining has happened and reveals a new interface conversion (and we would need to run the dictPass again to use that dictionary entry).

@danscales danscales self-assigned this Nov 3, 2021
@gopherbot
Copy link

Change https://golang.org/cl/361260 mentions this issue: cmd/compile: don't inline fn with no shape params, but passed a shape arg

@cuonglm cuonglm mentioned this issue Mar 25, 2022
Closed
@gopherbot
Copy link

Change https://go.dev/cl/424775 mentions this issue: cmd/compile: enable more inlining for unified IR

gopherbot pushed a commit that referenced this issue Aug 18, 2022
@mdempsky
cmd/compile: enable more inlining for unified IR
52016be 
The non-unified frontend had repeated issues with inlining and
generics (#49309, #51909, #52907), which led us to substantially
restrict inlining when shape types were present.

However, these issues are evidently not present in unified IR's
inliner, and the safety restrictions added for the non-unified
frontend can simply be disabled in unified mode.

Fixes #54497.

Change-Id: I8e6ac9f3393c588bfaf14c6452891b9640a9d1bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/424775
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
@golang golang locked and limited conversation to collaborators Aug 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@inso @danscales @cuonglm @gopherbot