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: compiler error: Dictionary should have already been generated #50561

Closed
csgura opened this issue Jan 12, 2022 · 2 comments
Closed

cmd/compile: compiler error: Dictionary should have already been generated #50561

csgura opened this issue Jan 12, 2022 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.18

Comments

@csgura
Copy link

csgura commented Jan 12, 2022 •
edited

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

$ go version
go version devel go1.18-3d3f5d91 Wed Jan 12 01:49:33 2022 +0000 darwin/arm64

Does this issue reproduce with the latest release?

Yes

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

The Gotip Playground

What did you do?

https://gotipplay.golang.org/p/CNITc5Yr7c1

I ran gotip build
( gotip run main.go does not generate the error. )

What did you expect to see?

No Error

What did you see instead?

# goerror
<autogenerated>:1: internal compiler error: Dictionary should have already been generated: goerror/fp..dict.Try[*goerror/diameter.ByteBuffer].IsSuccess

goroutine 1 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x2ab00?, 0xc0?}, {0xd3f7f7, 0x34}, {0xc0000be750, 0x2, 0x2})
	/usr/local/go/src/cmd/compile/internal/base/print.go:227 +0x1ca
cmd/compile/internal/base.Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/reflectdata.getDictionary(0xc0004a6370, {0xc0000acb80?, 0x1, 0x1})
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:2072 +0x2dd
cmd/compile/internal/reflectdata.methodWrapper(0xc0000db8f0, 0xc0004a63c0, 0x95?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1910 +0xefd
cmd/compile/internal/reflectdata.methods(0xc0000db8f0)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:351 +0x3c5
cmd/compile/internal/reflectdata.uncommonSize(...)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:79
cmd/compile/internal/reflectdata.dcommontype(0xc00002c4f0?, 0xc0000db8f0)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:725 +0x1cc
cmd/compile/internal/reflectdata.writeType(0xc0004a4ee0?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1150 +0x307
cmd/compile/internal/reflectdata.dcommontype(0x7f0bcc9e725b?, 0xc0004a4ee0)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:698 +0xbc
cmd/compile/internal/reflectdata.writeType(0x138ff00?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1175 +0x10aa
cmd/compile/internal/reflectdata.writeType(0xc0003fa540?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1021 +0x13cd
cmd/compile/internal/reflectdata.writeType(0xc0003e0930?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1057 +0xd54
cmd/compile/internal/reflectdata.writeType(0xc0004b6a10?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:990 +0x3ca
cmd/compile/internal/reflectdata.writeType(0xc00039d500?)
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1159 +0x100a
cmd/compile/internal/reflectdata.WriteRuntimeTypes()
	/usr/local/go/src/cmd/compile/internal/reflectdata/reflect.go:1266 +0x3d8
cmd/compile/internal/gc.dumpdata()
	/usr/local/go/src/cmd/compile/internal/gc/obj.go:118 +0x6e
cmd/compile/internal/gc.Main(0xd4bd20)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:328 +0x11ab
main.main()
	/usr/local/go/src/cmd/compile/main.go:55 +0xdd
@ALTree
Copy link
Member

ALTree commented Jan 12, 2022

Another issue with a similar error: #48185.

cc @danscales

@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 12, 2022
@ALTree ALTree added this to the Go1.18 milestone Jan 12, 2022
@danscales danscales self-assigned this Jan 12, 2022
@gopherbot
Copy link

Change https://golang.org/cl/378154 mentions this issue: cmd/compile: descend through types to find fully-instantiated types

jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
@danscales @jproberts
cmd/compile: descend through types to find fully-instantiated types
3eab570 
In order to make sure we export the dictionaries/shape methods for all
fully-instantiated types in inlineable functions, we need to descend
fully into types. For example, we may have a map type (e.g.
map[transactionID]Promise[*ByteBuffer]), where the key or value is a new
fully-instantiated type. So, I add a new checkFullyInst() traversal
function, which traverses all encountered types, but maintains a map, so
it only traverse it type once. We need to descend fully into interfaces,
structs, and methods, since a fully-instantiated type make occur in any
fields or arguments/results of methods, etc.

Fixes golang#50561

Change-Id: I88681a30384168539ed7229eed709f4e73ff0666
Reviewed-on: https://go-review.googlesource.com/c/go/+/378154
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 Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@danscales @ALTree @gopherbot @csgura