aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/mbitmap_allocheaders.go
diff options
context:
space:
mode:
authorThan McIntosh <thanm@google.com>2024-01-09 15:06:15 +0000
committerGopher Robot <gobot@golang.org>2024-01-10 15:27:52 +0000
commit8c1349baf7da63de98cf2b2764607ceec37b6283 (patch)
treea0b42d23a5caedf852adea9a6d42235f49a44812 /src/runtime/mbitmap_allocheaders.go
parent1d45a7ef560a76318ed59dfdb178cecd58caf948 (diff)
downloadgo-8c1349baf7da63de98cf2b2764607ceec37b6283.tar.xz
cmd/compile: use hashed symbol name for go.shape types if too long
Shape-based stenciling in the Go compiler's generic instantiation phase looks up shape types using the underlying type of a given target type. This has a beneficial effect in most cases (e.g. we can use the same shape type for two different named types whose underlying type is "int"), but causes some problems when the underlying type is a very large structure. The link string for the underlying type of a large imported struct can be extremely long, since the link string essentially enumerates the full package path for every field type; this can produce a "go.shape.struct { ... " symbol name that is absurdly long. This patch switches the compiler to use a hash of the underlying type link string instead of the string itself, which should continue to provide commoning but keep symbol name lengths reasonable for shape types based on large imported structs. Fixes #65030. Change-Id: I87d602626c43172beb99c186b8ef72327b8227a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/554975 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Diffstat (limited to 'src/runtime/mbitmap_allocheaders.go')
0 files changed, 0 insertions, 0 deletions