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 compiler error: method Len on *uint8 not found #54225

Closed
andig opened this issue Aug 3, 2022 · 20 comments
Closed

cmd/compile: internal compiler error: method Len on *uint8 not found #54225

andig opened this issue Aug 3, 2022 · 20 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge generics Issue is related to generics NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@andig
Copy link
Contributor

andig commented Aug 3, 2022

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

$ go version
go version go1.19 darwin/arm64

Does this issue reproduce with the latest release?

yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/andig/sdk/go1.19"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/andig/sdk/go1.19/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/yorkie/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build2796829895=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.19 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.19
uname -v: Darwin Kernel Version 21.6.0: Sat Jun 18 17:05:47 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	12.5
BuildVersion:	21G72
lldb --version: lldb-1316.0.9.46
Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)

What did you do?

Build https://github.com/yorkie-team/yorkie by running

go build ./...

What did you expect to see?

Success

What did you see instead?

go1.19 build ./...
go: downloading go.mongodb.org/mongo-driver v1.9.1
go: downloading github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0
go: downloading github.com/stretchr/testify v1.7.5
go: downloading github.com/hashicorp/go-immutable-radix v1.3.1
go: downloading go.etcd.io/etcd/client/pkg/v3 v3.5.4
go: downloading github.com/youmark/pkcs8 v0.0.0-20201027041543-1326539a0a0a
go: downloading github.com/coreos/go-semver v0.3.0
go: downloading github.com/go-stack/stack v1.8.1
go: downloading github.com/golang/snappy v0.0.4
go: downloading github.com/xdg-go/scram v1.1.1
go: downloading github.com/xdg-go/stringprep v1.0.3
go: downloading github.com/coreos/go-systemd/v22 v22.3.2
go: downloading github.com/xdg-go/pbkdf2 v1.0.0
# github.com/yorkie-team/yorkie/pkg/document/json
pkg/document/json/rga_tree_split.go:302:29: internal compiler error: method Len on *uint8 not found

The code is in https://github.com/yorkie-team/yorkie/blob/main/pkg/document/json/rga_tree_split.go#L299 which uses generics.

Refs: yorkie-team/yorkie#378

@cuonglm
Copy link
Member

cuonglm commented Aug 3, 2022

git bisect points to https://go-review.googlesource.com/c/go/+/385274 cc @randall77

@cuonglm cuonglm added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. generics Issue is related to generics labels Aug 3, 2022
@andig
Copy link
Contributor Author

andig commented Aug 3, 2022

It does build with GOEXPERIMENT=unified

@dmitshur dmitshur added this to the Go1.20 milestone Aug 3, 2022
@dmitshur
Copy link
Contributor

dmitshur commented Aug 3, 2022

CC @golang/compiler.

@dmitshur dmitshur changed the title go/build: internal compiler error: method Len on *uint8 not found cmd/compile: internal compiler error: method Len on *uint8 not found Aug 3, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 3, 2022
@ssorren
Copy link

ssorren commented Aug 15, 2022

I'm running into this error as well. The module in question builds fine, but when I try to import it into another project, I hit this error. Trying to come up with a short example, but the module in question is quite large and I'm not sure yet where the issue is. When the compiler fails with "method [X] on *uint8 not found", the file it fails on seems to be random. It changes depending on the code-base of the importing module. I will try to get an example going, but it's a bit like blindly poking around with a stick.

error from importing module1:

.../stores/sharded_tree.go:65:36: internal compiler error: method ReceiveChange on *uint8 not found

error from importing module2:

.../eos_producer.go:53:18: internal compiler error: method ReceiveChange on *uint8 not found

Neither sharded_tree.go nor eos_producer.go define ReceiveChange, but they both depend on a generic type that does.

It does build with "GOEXPERIMENT=unified". But not sure I'm too comfortable with that flag in a production workflow/ Downgrading to 1.18.x for the time being. Will post an example when I'm able to produce one

@andig
Copy link
Contributor Author

andig commented Aug 15, 2022

@ssorren the link I‘ve posted is public as repro, though large…

@ssorren
Copy link

ssorren commented Aug 15, 2022

@andig I get it. My repo is private still. Can't be made public yet. Trying to reproduce in small public example that won't get me fired :) but the error is hard to reproduce consistently

@mdempsky
Copy link
Contributor

Not fully minimized yet, but at least a standalone repro:

package json

type SplayTree[V any] struct{}

func (t *SplayTree[V]) Find(index int) {}

type Value interface {
        Len() int
}

type Node[V Value] struct{}

func (s *Node[V]) contentLen() int {
        var value V
        return value.Len()
}

type Split[V Value] struct{}

func (s *Split[V]) findNodePos(index int) {
        var treeByIndex *SplayTree[*Node[V]]
        treeByIndex.Find(index)
}

type TextValue struct{}

func (t *TextValue) Len() int { return 0 }

var x *Split[*TextValue]

@mdempsky
Copy link
Contributor

Further minimized: https://go.dev/play/p/WU6EOKRqM_V

It seems to be an issue around creating subdictionaries with derived types for the Two[Node[V]]() call, and that we're creating the dictionary with the shaped type argument instead of the unshaped one.

@cuonglm
Copy link
Member

cuonglm commented Aug 27, 2022

This is now fixed at tip, could we close? @mdempsky

@mdempsky
Copy link
Contributor

@cuonglm Not yet. It's still a regression from 1.18 to 1.19, which deserves a backport fix if we can prepare one that we have confidence in.

@cuonglm
Copy link
Member

cuonglm commented Aug 31, 2022

It seems to be an issue around creating subdictionaries with derived types for the TwoNode[V] call, and that we're creating the dictionary with the shaped type argument instead of the unshaped one.

Yes, I think it's understandable, because irgen maps all types with the same underlying type to the same shape.

Maybe we should never create method expression closure for shape type, or just relaxing g.finalizeSyms to not complain if the method receiver has no methods at all (after calling types.CalcMethods on the method expression receiver).

cc @randall77

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/428356 mentions this issue: cmd/compile: skip method expression closure check for un-used subdict

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/429655 mentions this issue: cmd/compile: skip emitting dictionaries with missing method expressions

@gopherbot

This comment was marked as off-topic.

gopherbot pushed a commit that referenced this issue Sep 19, 2022
The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.

The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.

This CL is a minimally invasive solution to #54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.

Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.

Updates #54225.

Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
@subokuma
Copy link

Hi @cuonglm
Thanks, Is any plan for this fix to be backported in Go 1.19.2 milestone?

@cuonglm
Copy link
Member

cuonglm commented Sep 20, 2022

Hi @cuonglm Thanks, Is any plan for this fix to be backported in Go 1.19.2 milestone?

Yes, the backport CL: https://go-review.googlesource.com/c/go/+/429895

Seems we lack of backport issue cc @mdempsky

@cherrymui
Copy link
Member

As this is working at tip, maybe we can close this and open a backport issue, where we can discuss the approach and risk of backporting? Thanks.

@mdempsky
Copy link
Contributor

@gopherbot Please backport to Go 1.19

@gopherbot
Copy link
Contributor

Backport issue(s) opened: #55270 (for 1.19).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@mdempsky
Copy link
Contributor

mdempsky commented Sep 20, 2022

Fixed at tip by CL 429655.

@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 Sep 20, 2022
gopherbot pushed a commit that referenced this issue Sep 21, 2022
…missing method expressions

The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.

The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.

This CL is a minimally invasive solution to #54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.

Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.

Fixes #55270.

Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429895
Reviewed-by: Keith Randall <khr@google.com>
bradfitz pushed a commit to tailscale/go that referenced this issue Oct 5, 2022
…missing method expressions

The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.

The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.

This CL is a minimally invasive solution to golang#54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.

Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.

Fixes golang#55270.

Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429895
Reviewed-by: Keith Randall <khr@google.com>
bradfitz pushed a commit to tailscale/go that referenced this issue Oct 5, 2022
…missing method expressions

The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.

The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.

This CL is a minimally invasive solution to golang#54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.

Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.

Fixes golang#55270.

Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429895
Reviewed-by: Keith Randall <khr@google.com>
bradfitz pushed a commit to tailscale/go that referenced this issue Oct 5, 2022
…missing method expressions

The nounified frontend currently tries to construct dictionaries that
correspond to invalid instantiations (i.e., instantiations T[X] where
X does not satisfy the constraints specified on T's type parameter).
As a consequence, we may fail to find method expressions needed by the
dictionary.

The real fix for this is to avoid creating those dictionaries in the
first place, because they should never actually be needed at runtime.
But that seems scary for a backport: we've repeatedly attempted to
backport generics fixes, which have fixed one issue but introduced
another.

This CL is a minimally invasive solution to golang#54225, which avoids the
ICE by instead skipping emitting the invalid dictionary. If the
dictionary ends up not being needed (which I believe will always be
the case), then the linker's reachability analysis will simply ignore
its absence.

Or worst case, if the dictionary *is* reachable somehow, we've simply
turned an ICE into a link-time missing symbol failure. That's not
great for user experience, but it seems like a small trade off to
avoid risking breaking any other currently working code.

Fixes golang#55270.

Change-Id: Ic379696079f4729b1dd6a66994a58cca50281a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/429655
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/429895
Reviewed-by: Keith Randall <khr@google.com>
@golang golang locked and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge generics Issue is related to generics NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

9 participants