x/tools/go/packages: preserve information about original errors #30379
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
I was looking at migrating a tool off of the golang.org/x/tools/go/loader package, as it is seemingly deprecated for use with Go modules, switching it onto https://godoc.org/golang.org/x/tools/go/packages. I ran into a disparity between the two packages in the type of errors that are available to the user after loading in the packages of interest.
A
loader.PackageInfo
provides a struct fieldErrors []error
, which allows one to do type introspection on the actual error returned from within the loading process.In contrast, the
packages.Package
has anErrors []Error
struct field, where all the errors from the underlying loading process have been one-way transformed into a new struct that loses information, or at least makes it harder to get at. That conversion process happens here: https://github.com/golang/tools/blob/83362c3779f5f48611068d488a03ea7bbaddc81e/go/packages/packages.go#L613-L660The specific use case I have is to introspect certain types of
types.Error
values so that the tool can then go and attempt to fix those errors in an automated fashion. Since thetypes.Error
gets stringified, that information is no longer readily available.Proposal
My proposal is to augment the
packages.Error
type to include anErr error
field that a user of the package can introspect further if desired.Alternative workarounds
One can write parsing logic for the current
Error.Pos
field based on what is currently done in the source code, but this seems unnecessary given that the underlying information was already present in a more structured form.The text was updated successfully, but these errors were encountered: