See #57505. Closing as a dup.

See #57505. Closing as a dup.

I don't think this issue is same as #57505.
Neither go1.19 nor go1.20 nor go1.20 with non-unified does inline the method of the generic type.
But in #57505, only go1.20 does not inline.

And I found that if we remove the field f1 in b.Boo struct or remove the variable x in main, then go1.20 will do inline the method, but go1.19 or non-unified will not inline.

b/b.go:

package b

func Bar() {
	var f1 Foo1[int]
	f1.Run()
	var f2 Foo2[int]
	f2.Run()
}

type Boo struct {
	f1 Foo1[int]
}

type Foo1[T any] struct {
}

func (*Foo1[T]) Run() {
}

type Foo2[T any] struct {
}

func (*Foo2[T]) Run() {
}

main.go:

package main

import "test/inlinegeneric/b"

func main() {
	var x b.Boo
	_ = x
	b.Bar()
}

go1.19.7 & go1.20 non-unified: None of the methods Run of Foo1[T] or Foo2[T] is inlined.

$ go1.19.7 build --gcflags="-m=2" ./main.go
# command-line-arguments
./main.go:5:6: can inline main with cost 29 as: func() { var x b.Boo; x = <nil>; _ = x; b.Bar() }
./main.go:8:7: inlining call to b.Bar
./b/b.go:17:17: can inline b.(*Foo1[go.shape.int_0]).Run with cost 0 as: func(uintptr, *b.Foo1[go.shape.int_0]) {  }

$ GOEXPERIMENT=nounified go1.20.2 build --gcflags="-m=2" ./main.go                                         [0](0s)[14:35:03]
# command-line-arguments
./main.go:5:6: can inline main with cost 29 as: func() { var x b.Boo; x = <nil>; _ = x; b.Bar() }
./main.go:8:7: inlining call to b.Bar
./b/b.go:17:17: can inline b.(*Foo1[go.shape.int_0]).Run with cost 0 as: func(uintptr, *b.Foo1[go.shape.int_0]) {  }

go1.20: Only Foo1[T].Run is not inlined, Foo2[T].Run is inlined. And the difference between Foo1[T] and Foo2[T] is that Boo has a field of type Foo1[T] and Boo is used in main package.

$ go1.20.2 build --gcflags="-m=2" ./main.go                                                             [146](38s)[14:35:00]
# command-line-arguments
./main.go:5:6: can inline main with cost 29 as: func() { x = <nil>; _ = x; b.Bar() }
./main.go:8:7: inlining call to b.Bar
./main.go:8:7: inlining call to b.(*Foo2[go.shape.int]).Run
./b/b.go:17:6: can inline b.(*Foo1[go.shape.int]).Run with cost 0 as: method(*b.Foo1[go.shape.int]) func(*[0]uintptr) {  }
./b/b.go:17:6: can inline b.(*Foo1[int]).Run with cost 9 as: method(*b.Foo1[int]) func() { var .autotmp_0 *b.Foo1[int]; .autotmp_0 = <nil>; (*b.Foo1[go.shape.int]).Run(.autotmp_0, &b..dict.Foo1[int]) }
./b/b.go:17:6: inlining call to b.(*Foo1[go.shape.int]).Run

Could you clarify which function(s) you expect to inline, but not? Is it a.(*Foo1[go.shape.int]).Run not inlined into main? Just pasting the diagnostics without explanation is not clear. Thanks.

And I found that if we remove the field f1 in b.Boo struct or remove the variable x in main, then go1.20 will do inline the method

So, it sounds like the two instantiations of a.Foo1[int], one in b.Boo and one in b.Bar (inlined into main) causes the compiler to confuse?

Also, it doesn't seem to require two levels of imports. Even if I put Foo1 and Foo2's definitions into package b, it seems (*Foo1[go.shape.int]).Run still not inlined into main.

cc @mdempsky @thanm @golang/compiler

Could you clarify which function(s) you expect to inline, but not? Is it a.(*Foo1[go.shape.int]).Run not inlined into main? Just pasting the diagnostics without explanation is not clear. Thanks.

Yes, a.(*Foo1[go.shape.int]).Run is expected to be inlined into main but actually not.

And I found that if we remove the field f1 in b.Boo struct or remove the variable x in main, then go1.20 will do inline the method

So, it sounds like the two instantiations of a.Foo1[int], one in b.Boo and one in b.Bar (inlined into main) causes the compiler to confuse?

Yes.

Also, it doesn't seem to require two levels of imports. Even if I put Foo1 and Foo2's definitions into package b, it seems (*Foo1[go.shape.int]).Run still not inlined into main.

cc @mdempsky @thanm @golang/compiler

Yes, no need package a.