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

andig · 2022-08-03T09:09:40Z

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

The text was updated successfully, but these errors were encountered:

cuonglm · 2022-08-03T09:41:57Z

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

andig · 2022-08-03T11:42:05Z

It does build with GOEXPERIMENT=unified

dmitshur · 2022-08-03T15:56:11Z

CC @golang/compiler.

ssorren · 2022-08-15T17:18:23Z

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 · 2022-08-15T20:14:13Z

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

ssorren · 2022-08-15T20:40:45Z

@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 · 2022-08-15T21:50:06Z

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 · 2022-08-15T22:03:48Z

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 · 2022-08-27T10:40:47Z

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

mdempsky · 2022-08-27T17:37:50Z

@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 · 2022-08-31T19:54:37Z

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 · 2022-09-05T07:19:19Z

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

gopherbot · 2022-09-08T21:39:09Z

Change https://go.dev/cl/429655 mentions this issue: cmd/compile: skip emitting dictionaries with 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. 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 · 2022-09-20T14:53:42Z

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

cuonglm · 2022-09-20T14:57:13Z

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 · 2022-09-20T15:27:27Z

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 · 2022-09-20T16:56:58Z

@gopherbot Please backport to Go 1.19

gopherbot · 2022-09-20T16:57:33Z

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 · 2022-09-20T17:07:59Z

Fixed at tip by CL 429655.

…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>

…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>

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

dmitshur added this to the Go1.20 milestone Aug 3, 2022

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 added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 3, 2022

mknyszek assigned dr2chase Aug 3, 2022

cuonglm mentioned this issue Aug 9, 2022

cmd/compile: internal compiler error: method X on struct {} not found #54356

Closed

KeisukeYamashita mentioned this issue Aug 18, 2022

Compilation fails with Go v1.19 reearth/reearthx#1

Closed

cuonglm mentioned this issue Aug 19, 2022

cmd/compile: stenciling fails due to confusion with underlying type through generic function call's call of a method on a generic function #54552

Closed

mdempsky mentioned this issue Sep 5, 2022

cmd/compile: internal compiler error for generic function on embedded struct #54471

Closed

cuonglm mentioned this issue Sep 7, 2022

cmd/compile: internal compiler error: method ToNumber on struct {} not found #54910

Closed

This comment was marked as off-topic.

Sign in to view

cuonglm mentioned this issue Sep 20, 2022

affected/package: Go build failed to compile in go1.19.1 but working 1.18 and dev branch #55240

Closed

gopherbot mentioned this issue Sep 20, 2022

cmd/compile: internal compiler error: method Len on *uint8 not found [1.19 backport] #55270

Closed

mdempsky closed this as completed Sep 20, 2022

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

cuonglm mentioned this issue Sep 29, 2022

sync/atomic: Generic type self-reference via atomic.Pointer causes internal compiler error #55938

Closed

hackerwins mentioned this issue Oct 8, 2022

Bump up Go to 1.19.2 yorkie-team/yorkie#425

Merged

2 tasks

seancfoley mentioned this issue Sep 2, 2023

internal compile rerror seancfoley/ipaddress-go#9

Closed

golang locked and limited conversation to collaborators Sep 20, 2023

gopherbot added the FrozenDueToAge label Sep 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

andig commented Aug 3, 2022 •

edited

cuonglm commented Aug 3, 2022

andig commented Aug 3, 2022

dmitshur commented Aug 3, 2022

ssorren commented Aug 15, 2022 •

edited

andig commented Aug 15, 2022

ssorren commented Aug 15, 2022

mdempsky commented Aug 15, 2022

mdempsky commented Aug 15, 2022

cuonglm commented Aug 27, 2022

mdempsky commented Aug 27, 2022

cuonglm commented Aug 31, 2022 •

edited

gopherbot commented Sep 5, 2022

gopherbot commented Sep 8, 2022

This comment was marked as off-topic.

subokuma commented Sep 20, 2022

cuonglm commented Sep 20, 2022

cherrymui commented Sep 20, 2022

mdempsky commented Sep 20, 2022

gopherbot commented Sep 20, 2022

mdempsky commented Sep 20, 2022 •

edited by dmitshur

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

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

Comments

andig commented Aug 3, 2022 • edited

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

cuonglm commented Aug 3, 2022

andig commented Aug 3, 2022

dmitshur commented Aug 3, 2022

ssorren commented Aug 15, 2022 • edited

andig commented Aug 15, 2022

ssorren commented Aug 15, 2022

mdempsky commented Aug 15, 2022

mdempsky commented Aug 15, 2022

cuonglm commented Aug 27, 2022

mdempsky commented Aug 27, 2022

cuonglm commented Aug 31, 2022 • edited

gopherbot commented Sep 5, 2022

gopherbot commented Sep 8, 2022

This comment was marked as off-topic.

subokuma commented Sep 20, 2022

cuonglm commented Sep 20, 2022

cherrymui commented Sep 20, 2022

mdempsky commented Sep 20, 2022

gopherbot commented Sep 20, 2022

mdempsky commented Sep 20, 2022 • edited by dmitshur

andig commented Aug 3, 2022 •

edited

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

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

ssorren commented Aug 15, 2022 •

edited

cuonglm commented Aug 31, 2022 •

edited

mdempsky commented Sep 20, 2022 •

edited by dmitshur