-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
git bisect points to https://go-review.googlesource.com/c/go/+/385274 cc @randall77 |
It does build with |
CC @golang/compiler. |
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:
error from importing module2:
Neither sharded_tree.go nor eos_producer.go define 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 |
@ssorren the link I‘ve posted is public as repro, though large… |
@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 |
Not fully minimized yet, but at least a standalone repro:
|
Further minimized: https://go.dev/play/p/WU6EOKRqM_V It seems to be an issue around creating subdictionaries with derived types for the |
This is now fixed at tip, could we close? @mdempsky |
@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. |
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 cc @randall77 |
Change https://go.dev/cl/428356 mentions this issue: |
Change https://go.dev/cl/429655 mentions this issue: |
This comment was marked as off-topic.
This comment was marked as off-topic.
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>
Hi @cuonglm |
Yes, the backport CL: https://go-review.googlesource.com/c/go/+/429895 Seems we lack of backport issue cc @mdempsky |
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. |
@gopherbot Please backport to Go 1.19 |
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. |
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>
…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>
…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>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Build https://github.com/yorkie-team/yorkie by running
What did you expect to see?
Success
What did you see instead?
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: