aboutsummaryrefslogtreecommitdiff
path: root/src/os/exec/exec.go
diff options
context:
space:
mode:
authorMatthew Dempsky <mdempsky@google.com>2022-04-29 10:47:57 -0700
committerGopher Robot <gobot@golang.org>2022-04-29 18:35:07 +0000
commit8c5917cd76905b1ab16d41eadc8786e190eeecce (patch)
tree976eab01e6911428e99ca13ca97e8a5b202c3af5 /src/os/exec/exec.go
parente7c56fe9948449a3710b36c22c02d57c215d1c10 (diff)
downloadgo-8c5917cd76905b1ab16d41eadc8786e190eeecce.tar.xz
cmd/compile: consistent unified IR handling of package unsafe
Within the unified IR export format, I was treating package unsafe as a normal package, but expecting importers to correctly handle deduplicating it against their respective representation of package unsafe. However, the surrounding importer logic differs slightly between cmd/compile/internal/noder (which unified IR was originally implemented against) and go/importer (which it was more recently ported to). In particular, noder initializes its packages map as `map[string]*types2.Package{"unsafe": types2.Unsafe}`, whereas go/importer initializes it as just `make(map[string]*types.Package)`. This CL makes them all consistent. In particular, it: 1. changes noder to initialize packages to an empty map to prevent further latent issues from the discrepency, 2. adds the same special handling of package unsafe already present in go/internal/gcimporter's unified IR reader to both of cmd/compile's implementations, and 3. changes the unified IR writer to treat package unsafe as a builtin package, to force that readers similarly handle it correctly. Fixes #52623. Change-Id: Ibbab9b0a1d2a52d4cc91b56c5df49deedf81295a Reviewed-on: https://go-review.googlesource.com/c/go/+/403196 Auto-Submit: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
Diffstat (limited to 'src/os/exec/exec.go')
0 files changed, 0 insertions, 0 deletions