x/tools/go/gcexportdata: Read to support only 2 Go releases + tip

[adonovan]

The gcexportdata package defines functions to export and import types.Packages as binary messages. They serve two purposes:

1. gcexportdata.{Write,Read} permit applications to serialize and deserialize type information. For example, gopls uses it for its index (database) of types.
2. gcexportdata.Read permits applications to read export data written by the Go compiler. For example, x/tools/go/packages uses this when NeedExport is set.

For (1), all that matters is that the Write and Read functions (at the exact same version) can faithfully round-trip all aspects of a types.Package; the form of the message isn't important. Currently, it uses the "indexed" (i) form, which the compiler used prior to its support for inlining and generics. This form is obsolete within GOROOT and is mentioned only in a few stale references, including documentation at cmd/compile/internal/typecheck/iexport.go. We plan to purge GOROOT of all mention to the i format, and move the docs to x/tools/internal.

For (2), what matters is that Read can read export data written by supported versions of the compiler. The compiler currently uses the "unified" (u) form. The gcexportdata package currently promises to "support[s] go1.7 export data format and all later versions". Given that almost all other promises of toolchain compatibility are limited to the last two Go releases (plus tip GOROOT), we propose to reduce Read's support window to match. (As a matter of fact, the code actually supports only as far back as go1.11.)

@timothy-king @griesemer @findleyr

[gabyhelp]

Related Issues and Documentation

• x/tools/go/gcexportdata: improved API to replace gcimporter15 #15651 (closed)
• x/tools/go/gcexportdata: support export using indexed format #28260 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/607495 mentions this issue: internal/gcimporter: move indexed format docs

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[adonovan]

After discussion with @griesemer, we agree that the support policy proposed here seems appropriate.

Furthermore, we agree that purpose (1), a serialization format for types.Packages, should really move into the go/types package where it will be easier to maintain, since it won't need all the cleverness each time the toolchain upgrades (witness: aliases). We'll file a separate proposal for that:

• proposal: go/types: add Import, Export functions #69491

[aclements]

Is there ever a reason a tool using gcexportdata would need to read old export data? I can't think of any, but want to put the question out there.

[timothy-king]

Is there ever a reason a tool using gcexportdata would need to read old export data? I can't think of any, but want to put the question out there.

You may want to ship a single tool that is compatible with analyzing the output of a large range of go toolchains. Today this would be something like creating a single binary that supports working with builds of both the 1.18 and 1.24 (tip) toolchains.

[adonovan]

You may want to ship a single tool that is compatible with analyzing the output of a large range of go toolchains.

This is more a description of the hypothetical tool than a motivation for it. In any case, you could still build such a tool by forking the old importer.