go/test/typeparam/issue50121b.dir/main.go

package main

import (
	"./d"
	"fmt"
)

func main() {
	if got, want := d.BuildInt(), 42; got != want {
		panic(fmt.Sprintf("got %d, want %d", got, want))
	}
}
cmd/compile: fix interaction between generics and inlining Finally figured out how to deal with the interaction between generics and inlining. The problem has been: what to do if you inline a function that uses a new instantiated type that hasn't been seen in the current package? This might mean that you need to do another round of function/method instantiatiations after inlining, which might lead to more inlining, etc. (which is what we currently do, but it's not clear when you can stop the inlining/instantiation loop). We had thought that one solution was to export instantiated types (even if not marked as exportable) if they are referenced in exported inlineable functions. But that was quite complex and required changing the export format. But I realized that we really only need to make sure the relevant dictionaries and shape instantiations for the instantiated types are exported, not the instantiated type itself and its wrappers. The instantiated type is naturally created as needed, and the wrappers are generated automatically while writing out run-time type (making use of the exported dictionaries and shape instantiations). So, we just have to make sure that those dictionaries and shape instantiations are exported, and then they will be available without any extra round of instantiations after inlining. We now do this in crawler.go. This is especially needed when the instantiated type is only put in an interface, so relevant dictionaries/shape instantiations are not directly referenced and therefore exported, but are still needed for the itab. This fix avoids the phase ordering problem where we might have to keep creating new type instantiations and instantiated methods after each round of inlining we do. Removed the extra round of instantiation/inlining that were added in the previous fix. The existing tests test/typeparam{geninline.go,structinit.go} already test this situation of inlining a function referencing a new instantiated type. Added the original example from issue 50121 as test (has 5 packages), since it found a problem with this code that the current simpler test for 50121 did not find. Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/375494 Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> 2021-12-29 15:08:55 +00:00			`package main`

			`import (`
test: use dot-relative imports where appropriate Currently, run.go's *dir tests allow "x.go" to be imported interchangeably as either "x" or "./x". This is generally fine, but can cause problems when "x" is the name of a standard library package (e.g., "fixedbugs/bug345.dir/io.go"). This CL is an automated rewrite to change all `import "x"` directives to use `import "./x"` instead. It has no effect today, but will allow subsequent CLs to update test/run.go to resolve "./x" to "test/x" to avoid stdlib collisions. Change-Id: Ic76cd7140e83b47e764f8a499e59936be2b3c876 Reviewed-on: https://go-review.googlesource.com/c/go/+/395116 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> 2022-03-23 22:09:31 +00:00			`"./d"`
cmd/compile: fix interaction between generics and inlining Finally figured out how to deal with the interaction between generics and inlining. The problem has been: what to do if you inline a function that uses a new instantiated type that hasn't been seen in the current package? This might mean that you need to do another round of function/method instantiatiations after inlining, which might lead to more inlining, etc. (which is what we currently do, but it's not clear when you can stop the inlining/instantiation loop). We had thought that one solution was to export instantiated types (even if not marked as exportable) if they are referenced in exported inlineable functions. But that was quite complex and required changing the export format. But I realized that we really only need to make sure the relevant dictionaries and shape instantiations for the instantiated types are exported, not the instantiated type itself and its wrappers. The instantiated type is naturally created as needed, and the wrappers are generated automatically while writing out run-time type (making use of the exported dictionaries and shape instantiations). So, we just have to make sure that those dictionaries and shape instantiations are exported, and then they will be available without any extra round of instantiations after inlining. We now do this in crawler.go. This is especially needed when the instantiated type is only put in an interface, so relevant dictionaries/shape instantiations are not directly referenced and therefore exported, but are still needed for the itab. This fix avoids the phase ordering problem where we might have to keep creating new type instantiations and instantiated methods after each round of inlining we do. Removed the extra round of instantiation/inlining that were added in the previous fix. The existing tests test/typeparam{geninline.go,structinit.go} already test this situation of inlining a function referencing a new instantiated type. Added the original example from issue 50121 as test (has 5 packages), since it found a problem with this code that the current simpler test for 50121 did not find. Change-Id: Iac5d0dddf4be19376f6de36ee20a83f0d8f213b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/375494 Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> 2021-12-29 15:08:55 +00:00			`"fmt"`
			`)`

			`func main() {`
			`if got, want := d.BuildInt(), 42; got != want {`
			`panic(fmt.Sprintf("got %d, want %d", got, want))`
			`}`
			`}`