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/internal/types2: unify.go:449: assertion failed, panic #67872

Closed
kevinburke opened this issue Jun 7, 2024 · 11 comments
Closed

cmd/compile/internal/types2: unify.go:449: assertion failed, panic #67872

kevinburke opened this issue Jun 7, 2024 · 11 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@kevinburke
Copy link
Contributor

Go version

go version devel go1.23-cf501e05e1 Thu Jun 6 21:59:21 2024 +0000 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE='off'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/kburke/Library/Caches/go-build'
GOENV='/Users/kburke/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/kburke/pkg/mod'
GONOPROXY='github.com/segmentio'
GONOSUMDB='github.com/segmentio'
GOOS='darwin'
GOPATH='/Users/kburke'
GOPRIVATE='github.com/segmentio'
GOPROXY='direct'
GOROOT='/Users/kburke/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/kburke/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='devel go1.23-cf501e05e1 Thu Jun 6 21:59:21 2024 +0000'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/kburke/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD=''
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/9s/w0d5_1fx71j5f225g95vtx340000gn/T/go-build3319341203=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Attempted to run "go vet" or "golangci-lint" on company source code

What did you see happen?

I got the following stack trace. Unfortunately, I don't have time to dig into it or try to bisect the problem, but maybe the stack trace is enough of a clue.

<unknown line number>: internal compiler error: panic: ../../../../go/src/cmd/compile/internal/types2/unify.go:449: assertion failed

goroutine 1 [running]:
runtime/debug.Stack()
	../../../../go/src/runtime/debug/stack.go:26 +0x64
cmd/compile/internal/base.FatalfAt({0x9cda18?, 0x140?}, {0x104a5aa79, 0x9}, {0x140009cda48, 0x1, 0x1})
	../../../../go/src/cmd/compile/internal/base/print.go:230 +0x20c
cmd/compile/internal/base.Fatalf(...)
	../../../../go/src/cmd/compile/internal/base/print.go:195
cmd/compile/internal/gc.handlePanic()
	../../../../go/src/cmd/compile/internal/gc/main.go:53 +0x8c
panic({0x104c74f40?, 0x14000a4e100?})
	../../../../go/src/runtime/panic.go:785 +0x124
cmd/compile/internal/types2.(*Checker).handleBailout(0x1400036e700, 0x140009d10d8)
	../../../../go/src/cmd/compile/internal/types2/check.go:390 +0x9c
panic({0x104c74f40?, 0x14000a4e100?})
	../../../../go/src/runtime/panic.go:785 +0x124
cmd/compile/internal/types2.assert(0xf8?)
	../../../../go/src/cmd/compile/internal/types2/errors.go:25 +0x60
cmd/compile/internal/types2.(*unifier).nify(0x140009fd3f8, {0x104d65b68, 0x1400095d180}, {0x104d65c80, 0x1400095fa80}, 0x0, 0x0)
	../../../../go/src/cmd/compile/internal/types2/unify.go:449 +0x820
cmd/compile/internal/types2.(*unifier).unify(...)
	../../../../go/src/cmd/compile/internal/types2/unify.go:141
cmd/compile/internal/types2.(*Checker).infer(0x1400036e700, {0x1400058e2a0, 0x6e, 0x13}, {0x14000a4e070, 0x2, 0x2}, {0x140009c56c0, 0x2, 0x2}, ...)
	../../../../go/src/cmd/compile/internal/types2/infer.go:255 +0x8b0
cmd/compile/internal/types2.(*Checker).arguments(0x1400036e700, 0x140005b4d20, 0x140009c9940, {0x0, 0x0, 0x0}, {0x0, 0x0, 0x0}, {0x14000a4e040, ...}, ...)
	../../../../go/src/cmd/compile/internal/types2/call.go:608 +0x9a4
cmd/compile/internal/types2.(*Checker).callExpr(0x1400036e700, 0x14000a4c540, 0x140005b4d20)
	../../../../go/src/cmd/compile/internal/types2/call.go:295 +0x46c
cmd/compile/internal/types2.(*Checker).exprInternal(0x1400036e700, 0x0, 0x14000a4c540, {0x104d6ae00, 0x140005b4d20}, {0x0, 0x0})
	../../../../go/src/cmd/compile/internal/types2/expr.go:1431 +0xbc
cmd/compile/internal/types2.(*Checker).rawExpr(0x1400036e700, 0x0, 0x14000a4c540, {0x104d6ae00?, 0x140005b4d20?}, {0x0?, 0x0?}, 0x0)
	../../../../go/src/cmd/compile/internal/types2/expr.go:996 +0x128
cmd/compile/internal/types2.(*Checker).multiExpr(0x1400036e700, {0x104d6ae00, 0x140005b4d20}, 0x0)
	../../../../go/src/cmd/compile/internal/types2/expr.go:1621 +0x60
cmd/compile/internal/types2.(*Checker).initVars(0x1400036e700, {0x14000a3e378, 0x1, 0x1}, {0x140009cfc28, 0x1, 0x1}, {0x0, 0x0})
	../../../../go/src/cmd/compile/internal/types2/assignments.go:422 +0x100
cmd/compile/internal/types2.(*Checker).shortVarDecl(...)
	../../../../go/src/cmd/compile/internal/types2/assignments.go:570
cmd/compile/internal/types2.(*Checker).stmt(0x1400036e700, 0x3, {0x104d68728, 0x140005c29c0})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:466 +0x1898
cmd/compile/internal/types2.(*Checker).stmtList(0x1400036e700, 0x3, {0x140005c6100?, 0x104a53bc8?, 0x5?})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:120 +0x88
cmd/compile/internal/types2.(*Checker).stmt(0x1400036e700, 0x3, {0x104d685d8, 0x140005c2800})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:554 +0x628
cmd/compile/internal/types2.(*Checker).rangeStmt(0x1400036e700, 0x3, 0x140005ca000, 0x104d6f700?)
	../../../../go/src/cmd/compile/internal/types2/stmt.go:998 +0x534
cmd/compile/internal/types2.(*Checker).stmt(0x1400036e700, 0x0, {0x104d687d0, 0x140005ca000})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:642 +0x43c
cmd/compile/internal/types2.(*Checker).stmtList(0x1400036e700, 0x0, {0x140005be700?, 0x14000a3e258?, 0x0?})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:120 +0x88
cmd/compile/internal/types2.(*Checker).funcBody(0x1400036e700, 0x140005c99f0?, {0x140005ae350?, 0x1400058e2a0?}, 0x140009bb100, 0x140005c26c0, {0x0?, 0x0?})
	../../../../go/src/cmd/compile/internal/types2/stmt.go:40 +0x218
cmd/compile/internal/types2.(*Checker).funcDecl.func1()
	../../../../go/src/cmd/compile/internal/types2/decl.go:789 +0x44
cmd/compile/internal/types2.(*Checker).processDelayed(0x1400036e700, 0x0)
	../../../../go/src/cmd/compile/internal/types2/check.go:502 +0x150
cmd/compile/internal/types2.(*Checker).checkFiles(0x1400036e700, {0x14000642000, 0x17, 0x17})
	../../../../go/src/cmd/compile/internal/types2/check.go:448 +0x5c8
cmd/compile/internal/types2.(*Checker).Files(0x16bd96383?, {0x14000642000?, 0x0?, 0x0?})
	../../../../go/src/cmd/compile/internal/types2/check.go:408 +0x80
cmd/compile/internal/types2.(*Config).Check(0x140006371f0, {0x16bd96383?, 0x1400000e0b7?}, {0x14000642000, 0x17, 0x17}, 0x1400063e5a0)
	../../../../go/src/cmd/compile/internal/types2/api.go:480 +0x68
cmd/compile/internal/noder.checkFiles({0x0, {0x0, 0x0}}, {0x140000ee300, 0x17, 0x1044f3250?})
	../../../../go/src/cmd/compile/internal/noder/irgen.go:95 +0x4b4
cmd/compile/internal/noder.writePkgStub({0x0?, {0x0?, 0x0?}}, {0x140000ee300, 0x17, 0x17})
	../../../../go/src/cmd/compile/internal/noder/unified.go:307 +0x48
cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0x140000ee300?, 0x104c5d740?, 0x0?})
	../../../../go/src/cmd/compile/internal/noder/unified.go:183 +0x98
cmd/compile/internal/noder.LoadPackage({0x1400001e3d8, 0x17, 0x1a})
	../../../../go/src/cmd/compile/internal/noder/noder.go:77 +0x398
cmd/compile/internal/gc.Main(0x104d5da30)
	../../../../go/src/cmd/compile/internal/gc/main.go:200 +0xb4c
main.main()
	../../../../go/src/cmd/compile/main.go:57 +0x110) (typecheck)

What did you expect to see?

I expected to see vet emit output. I cannot reproduce the problem with Go 1.22.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 7, 2024
@mknyszek
Copy link
Contributor

mknyszek commented Jun 7, 2024

CC @golang/compiler

@mknyszek mknyszek added this to the Go1.23 milestone Jun 7, 2024
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 7, 2024
@mknyszek
Copy link
Contributor

mknyszek commented Jun 7, 2024

This seems new in Go 1.23.

@rsc
Copy link
Contributor

rsc commented Jun 8, 2024

These assertion failures should be improved to at least report the line number of the source code causing the assertion. That would let users try to trim down the code to a repro case. As it is, all they get is "somewhere there is a problem".

As the FAQ says, "[Assertions] are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code."

The compiler needs to do better here.

@kevinburke
Copy link
Contributor Author

I was able to isolate the panic to a single private file which I emailed to Russ and Michael.

@griesemer griesemer self-assigned this Jun 10, 2024
@griesemer
Copy link
Contributor

@kevinburke Hi Kevin, can you please share the single private file with me (gri@golang.org). I introduced the offending assert. Thanks.

@griesemer
Copy link
Contributor

@kevinburke No need for the private file anymore.

Reproducer:

package p

type A = uint8
type E uint8

func f[P A](P) {}

func g(e E) {
	f(e)
}

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/591975 mentions this issue: go/types, types2: add missing Unalias calls in type unifier

@griesemer
Copy link
Contributor

@kevinburke I am fairly certain the above CL fixes the issue you see in your larger program (it was a bug in the type unifier) - but please check as soon as this issue is closed (and thus the fix is submitted), thanks. I have only verified for the simplified reproducer.

@griesemer
Copy link
Contributor

@rsc Filed #67932 to address #67872 (comment) (we were planning to do this a while ago but never quite got around to it).

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 11, 2024
@kevinburke
Copy link
Contributor Author

Confirmed no more panic! Vet completes successfully. Thanks for the fast fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
Status: Done
Development

No branches or pull requests

7 participants