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: instantiation cycle error in method #65366

Closed
leaxoy opened this issue Jan 30, 2024 · 10 comments
Closed

cmd/compile: instantiation cycle error in method #65366

leaxoy opened this issue Jan 30, 2024 · 10 comments
Assignees
Labels
generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@leaxoy
Copy link

leaxoy commented Jan 30, 2024

Go version

1.21

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOOS='darwin'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.21.6/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.21.6/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.6'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/_5/gqm2bdhs6jg5vpcqx9rp17qh0000gn/T/go-build1059361469=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

https://go.dev/play/p/Rs1R0zaMrys

What did you see happen?

./prog.go:14:12: instantiation cycle:
./prog.go:16:38: E instantiated as []E

What did you expect to see?

no error occurred

@mknyszek
Copy link
Contributor

CC @golang/compiler, perhaps @griesemer specifically?

@mknyszek mknyszek added the generics Issue is related to generics label Jan 30, 2024
@mknyszek mknyszek changed the title types: generic: instantiation cycle cmd/compile: instantiation cycle error in method Jan 30, 2024
@mknyszek mknyszek added this to the Backlog milestone Jan 30, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jan 30, 2024
@mknyszek mknyszek added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed compiler/runtime Issues related to the Go compiler and/or runtime. labels Jan 30, 2024
@griesemer
Copy link
Contributor

Simpler case (playground):

package p

type T[E any] int

func (T[E]) m(T[[]E]) {}

@griesemer griesemer self-assigned this Jan 30, 2024
@griesemer
Copy link
Contributor

griesemer commented Jan 30, 2024

This is working as intended. Since the type parameter E is not used, you can simply remove it and the code will compile.

If the type parameter were used, this code couldn't be compiled, at least with the current implementation of Go which monomorphizes code (doesn't box generics): say, T is instantiated with int. That means it will have a method m(T[[]int]) producing a type T instantiated with []int. That type will have a method m(T[[][]int]). Which will give rise to that new type T[[][]int], etc. ad infinitum. Code generation would never stop.

PS:The monomorphization check doesn't consider whether a type parameter is used or not.

@griesemer
Copy link
Contributor

@mdempsky In case you want to add something to this.

@mdempsky
Copy link
Contributor

I agree the error here is expected and the monomorpic checker is working as intended.

@leaxoy
Copy link
Author

leaxoy commented Jan 31, 2024

@griesemer Thank for your explain. But I still have some doubts.

Is the limitation here caused by the current implementation of generics, or will there always be this limitation. Or as the generics iterate, this limitation will disappear.

If this restriction will disappear in the future, when will it happen and whether it will rely on other preparatory work? If this restriction will be lifted in the future, should this issue be kept open?

In addition, I have not encountered similar problems in other languages. I am not sure about the implementation in go, but I believe this can be solved.

Going back to the original proposition, that is to say, I have no way to implement the chunk method on slice?

So is there any compromise way to implement chunks? It doesn't involve implementing a lot of top-level functions.

@leaxoy
Copy link
Author

leaxoy commented Jan 31, 2024

I'm not sure I understand the unused E above.

The following example uses E, but still reports an error:

type slice[E any] struct{ elems []E }

func (s slice[E]) chunk(n int) slice[[]E] {
	return slice[[]E]{elems: [][]E{}}
}

@mdempsky
Copy link
Contributor

Is the limitation here caused by the current implementation of generics, or will there always be this limitation.

We want to ensure instantiation is guaranteed to reach a finite fixed point. If instantiating type T[X] requires instantiating type T[[]X], then we'll need T[[][]X], and so on. It never stops.

@griesemer
Copy link
Contributor

@leaxoy The limitation could (perhaps) be removed if we'd always box generic values. But because our implementation uses a hybrid approach that monomorphizes code (generates code for each kind of type, for speed), your source would lead to endless code generation as @mdempsky pointed out. There are no plans to change this.

Your chunk implementation can be written like so:

func chunk[E any](s []E, n int) [][]E {
	do something sensible here
}

It's not a method but it also doesn't refer to itself anymore.

@leaxoy
Copy link
Author

leaxoy commented Feb 1, 2024

func chunk[E any](s []E, n int) [][]E {
	do something sensible here
}

But this break method chaining, maybe pipe-operator like cpp's ranges can solve user experience problems to a certain extent, but it's a separate topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants