diff options
| author | Matthew Dempsky <mdempsky@google.com> | 2022-04-29 10:47:57 -0700 |
|---|---|---|
| committer | Gopher Robot <gobot@golang.org> | 2022-04-29 18:35:07 +0000 |
| commit | 8c5917cd76905b1ab16d41eadc8786e190eeecce (patch) | |
| tree | 976eab01e6911428e99ca13ca97e8a5b202c3af5 /src/internal/execabs/execabs.go | |
| parent | e7c56fe9948449a3710b36c22c02d57c215d1c10 (diff) | |
| download | go-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/internal/execabs/execabs.go')
0 files changed, 0 insertions, 0 deletions
