-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: internal compiler error: method Len on *uint8 not found [1.19 backport] #55270
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
Comments
The backport CL is https://go-review.googlesource.com/c/go/+/429895 It's intentionally minimally invasive to address the issue while minimizing risk of collateral damage. Specifically, instead of hitting an ICE while emitting broken dictionary symbols, it changes the compiler to skip emitting those symbols instead. If the symbols are actually needed, the consequence is this just turns an ICE into a linker failure: no real harm. But I believe in practice the broken symbols aren't actually needed in the final executable, and so the linker's reachability analysis will simply ignore the missing symbol. |
Change https://go.dev/cl/429895 mentions this issue: |
Closed by merging 3747bb2 to release-branch.go1.19. |
…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>
@mdempsky requested issue #54225 to be considered for backport to the next 1.19 minor release.
The text was updated successfully, but these errors were encountered: