tree 08510602afd4d50583233b79a5703731a726419d
parent d7fc4e7114a478d21092b3ab0ce243607ce74c34
author Alan Donovan <adonovan@google.com> 1673289869 -0500
committer Alan Donovan <adonovan@google.com> 1673978577 +0000

internal/gcimporter: preserve column and line in shallow iexport

Historically, export data has discarded source position information.
Originally not even line numbers were available; at some point
line and column numbers were stored, up to some fixed limit, but
more recently column numbers were again discarded.
Offset information has always been incorrect.

gopls is moving toward greater reliance on incremental operation
using a file-based cache of export data and other serializable
records that are similar in character. It is critical that it
be able to accurately recover file position information for
dependencies.

This change causes the iexport function to encode each object's
token.Pos as a pair (file, offset), where file indicates the
token.File and offset is a byte offset within the file.
The token.File is serialized as a filename and a delta-encoded
line-offset table. (We discard the lineInfos table that supports
//line directives because gopls no longer uses it.)
The iimport function constructs a token.File and calls SetLines,
and then all token.Pos values work exactly as they would with
source.

This causes about a 74% increase in size of the shallow export
data for the standard library: was 564KB, now 982KB.

token.File has a SetLines method but no GetLines. This change
must therefore resort to... unorthodox methods to retrieve the
field. Suggestions welcome.

This alternative encoding is enabled by using "shallow" mode,
which is effectively a license for gopls to do whatever it wants.
Again, suggestions welcome.

Updates golang/go#57708

Change-Id: I028ed669161e38a9a4672dd8d9cadb268a0cdd07
Reviewed-on: https://go-review.googlesource.com/c/tools/+/461215
Run-TryBot: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>