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.

Sign up for GitHub

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: internal compiler error: unexpected types2.Invalid #72887

Open
meln5674 opened this issue Mar 15, 2025 · 11 comments
Open

cmd/compile: internal compiler error: unexpected types2.Invalid #72887

meln5674 opened this issue Mar 15, 2025 · 11 comments
Assignees
@griesemer @mrkfrmn
Labels
BadErrorMessage Issues related compiler error messages that should be better. BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@meln5674
Copy link

Go version

go version go1.24.1 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/andrew/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/andrew/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2188541391=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/andrew/git/src/github.com/meln5674/goj-compiler-bug/go.mod'
GOMODCACHE='/home/andrew/git/pkg/mod'
GONOPROXY='github.com/meln5675/*'
GONOSUMDB='github.com/meln5675/*'
GOOS='linux'
GOPATH='/home/andrew/git/'
GOPRIVATE='github.com/meln5675/*'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go-1.24.1'
GOSUMDB='sum.golang.org'
GOTELEMETRY='off'
GOTELEMETRYDIR='/home/andrew/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go-1.24.1/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

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

This is not the original source this defect was discovered in, which is not publicly releasable. The above was derived by removing source elements until the error no longer occurred and then anonymizing names.

A few previous versions of go that I happened to have installed were spot checked across 1.23 and 1.22 and they all produced internal errors, so this is likely not a regression in 1.24.1 .

What did you see happen?

Received the following error message:

# <REDACTED: root package of module>
<unknown line number>: internal compiler error: unexpected types2.Invalid

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

This occurs identically locally and in the linked go playground.

What did you expect to see?

The command to either succeed or produce a usable error message.
@randall77
Copy link
Contributor

The command to either succeed or produce a usable error message.

Any idea which one? I cannot fathom whether this is legal Go code or not.

@meln5674
Copy link
Author

I am fairly certain this is legal, as the original code base compiled and executed correctly until a single new field was added, which, unsurprisingly, ended up as the "B" field in the anonymized example. go fmt works without issue, so it is at very least syntactically legal.

@seankhliao seankhliao changed the title internal compiler error: unexpected types2.Invalid cmd/compile: internal compiler error: unexpected types2.Invalid Mar 15, 2025
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Mar 15, 2025
@gabyhelp
Copy link

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

@gabyhelp gabyhelp added the BugReport Issues describing a possible bug in the Go implementation. label Mar 15, 2025
@meln5674
Copy link
Author

I have managed to simplify it further, along with a clearer naming scheme that disambiguates between types, fields, and type params: https://go.dev/play/p/bKryWGDZIep .

This makes it more obvious that there is a cycle in the type graph between B and D, which I originally believed to be the issue, but curiously, removing A fixes the error, as does making D a typedef for B directly or making B an alias for a pointer to D. It seems that it is this specific graph shape that triggers the bug.

@meln5674
Copy link
Author

Further progress: https://go.dev/play/p/5Pkrr97m2QT has an identical shape, but doesn't have the error. The only difference is that B is changed to a typedef of C, instead of an alias. I traced this back to what this represented in the original codebase, changed it from an alias to a typedef, and the original codebase compiles again. Something about that edge in the graph being an alias instead of a typedef must be the cause.

@ianlancetaylor
Copy link
Member

When using the alias these programs look invalid to me. They contain an invalid circular reference.

CC @griesemer @findleyr

@meln5674
Copy link
Author

Can you elaborate? B and D do not actually contain eachother in their representations, they are both empty structs by virtue of being an alias/typedef to C and E respectively, The reference is only in the type parameters. For example https://go.dev/play/p/yuQ_x9x_tA7 is valid, despite having the same circular reference in type parameters, and even having one (but not both) of the type edges be an alias.

@ianlancetaylor
Copy link
Member

A type alias means that you can substitute the name being defined with the right hand side. In the example https://go.dev/play/p/bKryWGDZIep after we substitute for TypeB we have type TypeD TypeE[TypeC[*TypeD]]. So TypeD is being defined in terms of itself. That's not the case when not using an alias: without the alias, there are different types that refer to each other.

That said, there are some cases where circular type definitions are OK. I suppose I don't really know whether this is one of them.

@findleyr
Copy link
Member

This panic was added in https://go.dev/cl/338973, in response to #25838.

Panicking stack:

runtime/debug.Stack()
	runtime/debug/stack.go:26 +0x5e
cmd/compile/internal/base.FatalfAt({0x139040?, 0xc0?}, {0xec4422, 0x19}, {0x0, 0x0, 0x0})
	cmd/compile/internal/base/print.go:230 +0x1ea
cmd/compile/internal/base.Fatalf(...)
	cmd/compile/internal/base/print.go:195
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b790, 0x15d9440}, 0xc000116500)
	cmd/compile/internal/noder/writer.go:533 +0x597
cmd/compile/internal/noder.(*writer).typ(0xc0003f5080, {0x102b790?, 0x15d9440?})
	cmd/compile/internal/noder/writer.go:481 +0x2f
cmd/compile/internal/noder.(*writer).doObj(0xc0003f5080, 0xc0003f5130, {0x10341e0, 0xc0004009c0})
	cmd/compile/internal/noder/writer.go:883 +0x318
cmd/compile/internal/noder.(*pkgWriter).objIdx(0xc000139040, {0x10341e0, 0xc0004009c0})
	cmd/compile/internal/noder/writer.go:815 +0x84b
cmd/compile/internal/noder.(*pkgWriter).objInstIdx(0xc000139040, {0x10341e0, 0xc0004009c0}, 0x0, 0xc000116460)
	cmd/compile/internal/noder/writer.go:756 +0xf4
cmd/compile/internal/noder.(*writer).obj(0xc0003f4fd0, {0x10341e0?, 0xc0004009c0?}, 0xc0001350a0?)
	cmd/compile/internal/noder/writer.go:730 +0x33
cmd/compile/internal/noder.(*writer).namedType(0xc0003f4fd0, 0xc0004009c0, 0x0)
	cmd/compile/internal/noder/writer.go:631 +0x52
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b6c8, 0xc0001350a0}, 0xc000116460)
	cmd/compile/internal/noder/writer.go:550 +0x8cc
cmd/compile/internal/noder.(*writer).typ(0xc0003f4f20, {0x102b6c8?, 0xc0001350a0?})
	cmd/compile/internal/noder/writer.go:481 +0x2f
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b678, 0xc000036bb0}, 0xc000116460)
	cmd/compile/internal/noder/writer.go:578 +0x875
cmd/compile/internal/noder.(*pkgWriter).objInstIdx(0xc000139040, {0x10341e0, 0xc000400960}, 0xc0003fe3a8, 0xc000116460)
	cmd/compile/internal/noder/writer.go:754 +0x99
cmd/compile/internal/noder.(*writer).obj(0xc0003f4e70, {0x10341e0?, 0xc000400960?}, 0xc0001351f0?)
	cmd/compile/internal/noder/writer.go:730 +0x33
cmd/compile/internal/noder.(*writer).namedType(0xc0003f4e70, 0xc000400960, 0xc0003fe3a8)
	cmd/compile/internal/noder/writer.go:631 +0x52
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b6c8, 0xc0001351f0}, 0xc000116460)
	cmd/compile/internal/noder/writer.go:550 +0x8cc
cmd/compile/internal/noder.(*writer).typ(0xc0003f4bb0, {0x102b6c8?, 0xc0001351f0?})
	cmd/compile/internal/noder/writer.go:481 +0x2f
cmd/compile/internal/noder.(*writer).doObj(0xc0003f4bb0, 0xc0003f4c60, {0x10341e0, 0xc000400900})
	cmd/compile/internal/noder/writer.go:873 +0x4c5
cmd/compile/internal/noder.(*pkgWriter).objIdx(0xc000139040, {0x10341e0, 0xc000400900})
	cmd/compile/internal/noder/writer.go:815 +0x84b
cmd/compile/internal/noder.(*pkgWriter).objInstIdx(0xc000139040, {0x10341e0, 0xc000400900}, 0x0, 0xc0001163c0)
	cmd/compile/internal/noder/writer.go:756 +0xf4
cmd/compile/internal/noder.(*writer).obj(0xc0003f4b00, {0x10341e0?, 0xc000400900?}, 0x1?)
	cmd/compile/internal/noder/writer.go:730 +0x33
cmd/compile/internal/noder.(*writer).namedType(0xc0003f4b00, 0xc000400900, 0x0)
	cmd/compile/internal/noder/writer.go:631 +0x52
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b6f0, 0xc0003fcf00}, 0xc0001163c0)
	cmd/compile/internal/noder/writer.go:554 +0x3e5
cmd/compile/internal/noder.(*writer).typ(0xc0003f4a50, {0x102b6f0?, 0xc0003fcf00?})
	cmd/compile/internal/noder/writer.go:481 +0x2f
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xc000139040, {0x102b678, 0xc000036b50}, 0xc0001163c0)
	cmd/compile/internal/noder/writer.go:578 +0x875
cmd/compile/internal/noder.(*writer).typ(0xc0003f46e0, {0x102b678?, 0xc000036b50?})
	cmd/compile/internal/noder/writer.go:481 +0x2f
cmd/compile/internal/noder.(*writer).doObj(0xc0003f46e0, 0xc0003f4790, {0x10341e0, 0xc0004008a0})
	cmd/compile/internal/noder/writer.go:883 +0x318
cmd/compile/internal/noder.(*pkgWriter).objIdx(0xc000139040, {0x10341e0, 0xc0004008a0})
	cmd/compile/internal/noder/writer.go:815 +0x84b
cmd/compile/internal/noder.(*pkgWriter).objInstIdx(0xc000139040, {0x10341e0, 0xc0004008a0}, 0x0, 0x0)
	cmd/compile/internal/noder/writer.go:756 +0xf4
cmd/compile/internal/noder.(*writer).obj(0xc0003f44d0, {0x10341e0?, 0xc0004008a0?}, 0x0?)
	cmd/compile/internal/noder/writer.go:730 +0x33
cmd/compile/internal/noder.writePkgStub({0x0?, {0x0?, 0x0?}}, {0xc0000686c0, 0x1, 0x1})
	cmd/compile/internal/noder/unified.go:343 +0x6fa
cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0xc0000686c0?, 0xdd9ce0?, 0x0?})
	cmd/compile/internal/noder/unified.go:195 +0xb3
cmd/compile/internal/noder.LoadPackage({0xc000020170, 0x1, 0x1})
	cmd/compile/internal/noder/noder.go:77 +0x43a
cmd/compile/internal/gc.Main(0xeeca88)
	cmd/compile/internal/gc/main.go:208 +0xcc5

@findleyr
Copy link
Member

Without digging too deeply, the problem seems to be that go/types creates a Typ[Invalid] without reporting an actual error. My guess is there is some inaccurate "error reported elsewhere" assumption.

@cherrymui cherrymui added BadErrorMessage Issues related compiler error messages that should be better. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 17, 2025
@cherrymui cherrymui added this to the Backlog milestone Mar 17, 2025
@griesemer
Copy link
Contributor

This is due to buggy cycle detection. For:

package main

type (
	A        B
	B        = C[D]
	C[_ any] struct{}
	D        E[B]
	E[_ any] struct{}
)

func main() {}

we get the following type-checking trace (excerpt, using go/types):

testdata/manual.go:4:2: -- checking type A (white, objPath = )
testdata/manual.go:4:11:        .  -- type B
testdata/manual.go:5:2: .  .  -- checking type B (white, objPath = A)
testdata/manual.go:5:13:        .  .  .  -- type C[D]
testdata/manual.go:5:13:        .  .  .  .  -- instantiating type C with [D]
testdata/manual.go:5:13:        .  .  .  .  .  -- type C
testdata/manual.go:6:2: .  .  .  .  .  .  -- checking type C (white, objPath = A->B)
testdata/manual.go:6:6: .  .  .  .  .  .  .  -- type any
testdata/manual.go:6:6: .  .  .  .  .  .  .  => any (under = any) // *Alias
testdata/manual.go:6:11:        .  .  .  .  .  .  .  -- type struct{}
testdata/manual.go:6:11:        .  .  .  .  .  .  .  => struct{} // *Struct
testdata/manual.go:6:2: .  .  .  .  .  .  => type C[_ any] struct{} (black)
testdata/manual.go:5:13:        .  .  .  .  .  => C[_₁ any] (under = struct{}) // *Named
testdata/manual.go:5:15:        .  .  .  .  .  -- type D
testdata/manual.go:7:2: .  .  .  .  .  .  -- checking type D (white, objPath = A->B)
testdata/manual.go:7:11:        .  .  .  .  .  .  .  -- type E[B]
testdata/manual.go:7:11:        .  .  .  .  .  .  .  .  -- instantiating type E with [B]
testdata/manual.go:7:11:        .  .  .  .  .  .  .  .  .  -- type E
testdata/manual.go:8:2: .  .  .  .  .  .  .  .  .  .  -- checking type E (white, objPath = A->B->D)
testdata/manual.go:8:6: .  .  .  .  .  .  .  .  .  .  .  -- type any
testdata/manual.go:8:6: .  .  .  .  .  .  .  .  .  .  .  => any (under = any) // *Alias
testdata/manual.go:8:11:        .  .  .  .  .  .  .  .  .  .  .  -- type struct{}
testdata/manual.go:8:11:        .  .  .  .  .  .  .  .  .  .  .  => struct{} // *Struct
testdata/manual.go:8:2: .  .  .  .  .  .  .  .  .  .  => type E[_ any] struct{} (black)
testdata/manual.go:7:11:        .  .  .  .  .  .  .  .  .  => E[_₂ any] (under = struct{}) // *Named
testdata/manual.go:7:13:        .  .  .  .  .  .  .  .  .  -- type B
testdata/manual.go:5:2: .  .  .  .  .  .  .  .  .  .  ## cycle detected: objPath = B->D->B (len = 2)
testdata/manual.go:5:2: .  .  .  .  .  .  .  .  .  .  ## cycle contains: 0 values, 1 type definitions
testdata/manual.go:5:2: .  .  .  .  .  .  .  .  .  .  => cycle is valid
testdata/manual.go:7:13:        .  .  .  .  .  .  .  .  .  => B (under = invalid type) // *Alias
testdata/manual.go:7:11:        .  .  .  .  .  .  .  .  => invalid type
testdata/manual.go:7:11:        .  .  .  .  .  .  .  => invalid type // *Basic
testdata/manual.go:7:2: .  .  .  .  .  .  => type D invalid type (black)
testdata/manual.go:5:15:        .  .  .  .  .  => D (under = invalid type) // *Named
testdata/manual.go:5:13:        .  .  .  .  => C[D]
testdata/manual.go:5:13:        .  .  .  => C[D] (under = <nil>) // *Named
testdata/manual.go:5:2: .  .  => type B = C[D] (black)
testdata/manual.go:4:11:        .  => B (under = <nil>) // *Alias
testdata/manual.go:5:13:        -- Named.expandUnderlying C[D]
testdata/manual.go:5:13:        => C[D] (tparams = [], under = <nil>)
testdata/manual.go:4:2: => type A struct{} (black)

A cycle is detected but deemed "Valid", however, the type for B is invalid and (likely) never set later.
Possibly related issues: Status: #68162, #68025, #60130.

Not sure there's an easy fix that doesn't simply push the problem around. We need to revamp/rewrite cycle detection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@griesemer griesemer

@mrkfrmn mrkfrmn

Labels
BadErrorMessage Issues related compiler error messages that should be better. BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Backlog
Development

No branches or pull requests
9 participants
@ianlancetaylor @randall77 @griesemer @gopherbot @cherrymui @meln5674 @findleyr @gabyhelp @mrkfrmn