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: found illegal assignment FUNC-func(int) error -> main.Fn[int]; #50177

Closed
gus opened this issue Dec 15, 2021 · 11 comments
Closed

cmd/compile: found illegal assignment FUNC-func(int) error -> main.Fn[int]; #50177

gus opened this issue Dec 15, 2021 · 11 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 release-blocker
Milestone

Comments

@gus
Copy link

gus commented Dec 15, 2021

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

$ go version
go version go1.18beta1 linux/amd64

Does this issue reproduce with the latest release?

Yes, assuming the latest version is gotip.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dev/.cache/go-build"
GOENV="/home/dev/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/dev/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/dev/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/dev/sdk/go1.18beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/dev/sdk/go1.18beta1/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/workspace/dev/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build929647144=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This came up as I was trying to write some table driven unit tests for some functions that allow for generics. I've reduced the problem to this:

https://gotipplay.golang.org/p/0FYmUq0bzvr

The issue appears only if the a type is declared with the same name within multiple functions of a package file, and there is a field on the types with the same name, but different signature.

If I rename one of the types in the caller* functions, I do not see the issue.

What did you expect to see?

Compiled code.

What did you see instead?

# command-line-arguments
./issue.go:22:14: internal compiler error: found illegal assignment FUNC-func(int) error -> main.Fn[int]; 

Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new
@ianlancetaylor
Copy link
Contributor

Thanks. Can you please include a short program that triggers the error?

@seankhliao seankhliao changed the title affected/package: cmd/compile: found illegal assignment FUNC-func(int) error -> main.Fn[int]; Dec 15, 2021
@gus
Copy link
Author

gus commented Dec 15, 2021

Thanks. Can you please include a short program that triggers the error?

Sorry, accidentally hit tab+enter prematurely. Issue updated with more details.

@ianlancetaylor
Copy link
Contributor

CC @danscales @randall77

(Compilation succeeds with GOEXPERIMENT=unified)

foo.go:22:14: internal compiler error: found illegal assignment FUNC-func(int) error -> main.Fn[int]; 

goroutine 1 [running]:
runtime/debug.Stack()
	/home/iant/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x0?, 0x0?}, {0xd36a84, 0x27}, {0xc000436c30, 0x3, 0x3})
	/home/iant/go/src/cmd/compile/internal/base/print.go:227 +0x1ca
cmd/compile/internal/base.Fatalf(...)
	/home/iant/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/noder.assignconvfn({0xe91250, 0xc0004277c0}, 0xc000439ab0)
	/home/iant/go/src/cmd/compile/internal/noder/transform.go:426 +0x1b2
cmd/compile/internal/noder.transformCompLit(0xc00013b300)
	/home/iant/go/src/cmd/compile/internal/noder/transform.go:980 +0x9f1
cmd/compile/internal/noder.(*irgen).compLit(0xc000152240, {0xe8d0b0, 0xc00013af80}, 0xc000407c70)
	/home/iant/go/src/cmd/compile/internal/noder/expr.go:372 +0x276
cmd/compile/internal/noder.(*irgen).expr0(0xc000152240, {0xe8d0b0, 0xc00013af80}, {0xe8e008?, 0xc000407c70?})
	/home/iant/go/src/cmd/compile/internal/noder/expr.go:107 +0x585
cmd/compile/internal/noder.(*irgen).expr(0xc000152240, {0xe8e008?, 0xc000407c70?})
	/home/iant/go/src/cmd/compile/internal/noder/expr.go:81 +0x5e8
cmd/compile/internal/noder.(*irgen).exprs(0xc000437360?, {0xc000437350, 0x1, 0xc00006cc30?})
	/home/iant/go/src/cmd/compile/internal/noder/expr.go:329 +0x8e
cmd/compile/internal/noder.(*irgen).exprList(0x0?, {0xe8e008?, 0xc000407c70?})
	/home/iant/go/src/cmd/compile/internal/noder/expr.go:312 +0x85
cmd/compile/internal/noder.(*irgen).stmt(0xc000152240, {0xe8de88?, 0xc000035c40?})
	/home/iant/go/src/cmd/compile/internal/noder/stmt.go:79 +0x418
cmd/compile/internal/noder.(*irgen).stmts(0xc000438a80?, {0xc000035cc0?, 0x3, 0xc00006d4a0?})
	/home/iant/go/src/cmd/compile/internal/noder/stmt.go:19 +0xaf
cmd/compile/internal/noder.(*irgen).funcBody(0xc000152240, 0xc000413080, 0xb4d7a0?, 0xc000035ac0, 0xc000035b00)
	/home/iant/go/src/cmd/compile/internal/noder/func.go:45 +0x25f
cmd/compile/internal/noder.(*irgen).funcDecl.func1()
	/home/iant/go/src/cmd/compile/internal/noder/decl.go:145 +0xf5
cmd/compile/internal/noder.(*irgen).generate(0xc000152240, {0xc00000e430, 0x1, 0x203000?})
	/home/iant/go/src/cmd/compile/internal/noder/irgen.go:280 +0x227
cmd/compile/internal/noder.check2({0xc00000e430, 0x1, 0x1})
	/home/iant/go/src/cmd/compile/internal/noder/irgen.go:92 +0x16d
cmd/compile/internal/noder.LoadPackage({0xc00001e1f0, 0x1, 0x0?})
	/home/iant/go/src/cmd/compile/internal/noder/noder.go:90 +0x335
cmd/compile/internal/gc.Main(0xd4a7e8)
	/home/iant/go/src/cmd/compile/internal/gc/main.go:191 +0xb13
main.main()
	/home/iant/go/src/cmd/compile/main.go:55 +0xdd

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 15, 2021
@ianlancetaylor ianlancetaylor added this to the Go1.18 milestone Dec 15, 2021
@ianlancetaylor ianlancetaylor added okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 release-blocker labels Dec 15, 2021
@randall77
Copy link
Contributor

I don't think this will work currently. We don't allow local type declarations (or functions for that matter) with generic parameters.
Or at least, we shouldn't. Definitely needs a better error message.

Somewhat related to #47631 except it's a generic type declaration in a non-generic function, instead of a non-generic type declaration in a generic function.

@gus
Copy link
Author

gus commented Dec 15, 2021

Thanks, @randall77 . More than happy to be told not to do this as I didn't really like the way the test was looking anyway; but gopls wasn't complaining, so I forged ahead. I will add that if the signature for fn in both X types is the same, then the code compiles (and works if you add a main function to the example).

@randall77
Copy link
Contributor

@gri @ianlancetaylor @findleyr @danscales

I guess we need to decide whether we support local declarations of generic types in non-generic functions. Maybe we could? I'm not sure if this doesn't work because we never tried it, or because it's not supposed to work, or because it should work but doesn't. Opinions welcome.

I have a CL ready to officially make this an error like for #47631, but that's only if we decide it is the right thing to do.

@gopherbot
Copy link

Change https://golang.org/cl/372154 mentions this issue: cmd/compile: don't allow generic type declarations inside functions

@danscales
Copy link
Contributor

It looks like we are confusing the two local named types X incorrectly. If you rename the second local type to Y, things work fine. We don't have the same confusion for non-generic local types, so must be some generic-only state. I will take a further look.

However, I would say, for this release, it is probably less confusing to the user and reduces the number of possible unusual cases if we disallow local generic type declarations in non-generic functions.

@ianlancetaylor
Copy link
Contributor

I think that eventually we should support local declarations of generic types in non-generic functions, but I think it's fine if we don't support that in 1.18.

@gopherbot
Copy link

Change https://golang.org/cl/372654 mentions this issue: cmd/compile: pop instantiations of local types when leaving scope

@danscales
Copy link
Contributor

The problem is that instantiations of local types need to be popped from the symbol table when leaving the scope of the local type, else they might get used for an instantiation of a later same-name local type. I have the relatively simple fix above, but still need to think about other possible issues, since local generic types was not a focus for the code and we have no tests.

jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
Since we use existing instantiations from the symbol table when possible
(to make sure each instantiation is unique), we need to pop
instantiations of local types when leaving the containing scope.
g.stmts() now pushes and pops scope, and we do a Pushdcl() in g.typ0()
when creating an instantiation of a local type.

Non-instantiated local types (generic or not) are translated directly
from types2, so they don't need to be pushed/popped. We don't export
function bodies with local types, so there is no issue during import.

We still don't support local types in generic functions/methods.

Fixes golang#50177

Change-Id: If2d2fe71aec003d13f0338565c7a0da2c9580a14
Reviewed-on: https://go-review.googlesource.com/c/go/+/372654
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Jan 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. okay-after-beta1 Used by release team to mark a release-blocker issue as okay to resolve either before or after beta1 release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants