Go version
go version go1.24.5 windows/amd64
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=1
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\telic\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=gotypesalias=1
set GOENV=C:\Users\telic\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=aliastypeparams
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\telic\AppData\Local\Temp\go-build2309082198=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=NUL
set GOMODCACHE=C:\Users\telic\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\telic\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=on
set GOTELEMETRYDIR=C:\Users\telic\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.24.5
set GOWORK=
set PKG_CONFIG=pkg-config
What did you do?
Ran this playground code.
What did you see happen?
The subpackage types/compile compiles, while the subpackage types/broken does not.
The subpackages contains the exact same type declarations, just in the opposite order.
What did you expect to see?
I was under the impression that package-level type declarations could be declared in any order, so I expected them to have the same outcome (probably to both compile).
Comment From: gabyhelp
Related Issues
- cmd/compile: declaration order of types affects cycle detection #68025
- cmd/compile: inconsistent typechecking with self-referential type parameter constraints #65714
- cmd/compile: type checking succeeds/fails depending on declaration order #52698 (closed)
- cmd/compile/internal/types2: invalid recursive type not detected and panics #48096 (closed)
- gccgo: internal compiler error with simple recursive type declaration #25320 (closed)
- cmd/compile: declaring a variable before a particular type definition causes compiler crash #50276 (closed)
- go/types: recursive type aliases might cause a panic #71284 (closed)
- go/types, cmd/compile: "invalid type loop" depending on declaration order #51244
- cmd/compile: cyclic constraints are not detected #69589 (closed)
- cmd/compile: internal compiler error: unexpected types2.Invalid #72887
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: mrkfrmn
This looks like another bug with cycle detection — particularly around management of the object path. Surprisingly there are 2 issues here: - The same cycle is reported twice. - That cycle is legal.
I suspect that we are mishandling the lifecycle around instantiation here, which induces a full type check where it's not necessary — I have not done a thorough investigation. I think we plan to overhaul cycle detection nearly entirely, so this will likely be rolled into that fix.
Perhaps a hotlist for cycle detection bugs is in order.