gabyhelp
commented
1 month ago 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
rsc
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.Readpermits 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 theiformat, and move the docs to x/tools/internal.For (2), what matters is that
Readcan 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