Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
go/types, x/tools/gopls: improve the positioning of type checker errors #42290
This issue tracks work in both go/types and gopls to improve the position information associated with type checker errors.
Errors produced by go/types currently consist (mostly) of an error message and a position in the source. Related errors are grouped by prefixing continuation errors with
There are two limitations of
After discussing with @griesemer the tentative plan is to
We’re still not sure what the correct API is for these, but we’d like to at least start defining error codes internally for 1.16 (CL 264179).
I'm opening this issue to track that work, as well as any progress we make on defining the API.
Tools using go/types sometimes need to implement special handling for certain errors produced by the type-checker. They can offer suggested fixes, expand the error position to surrounding syntax, highlight related syntax (for example in the case of a declaration cycle), link to additional documentation, group errors by category, or correlate errors with signals produced by other static analysis tools. All these require a notion of error identity. Tools need to be able to reliably determine the nature of an error without re-implementing type checking logic or parsing error messages. This CL is a first-pass at adding such an identifier to types.Error: a (for the moment unexported) field containing one of many declared errorCode constants. A wide variety of error code constants are defined, and assigned to type checker errors according to their 'functional equivalence', meaning that they should be ideally be stable under refactoring. With few exceptions, each error code is documented with an example that produces it. This is enforced by tests. When error codes are exported they will represent quite a large API surface. For this reason, as well as the likelihood that error codes will change at the start, both the code field and the codes themselves are initially unexported. gopls will read these fields using reflection during this experimental phase. Others can obviously do the same, provided they accept the lack of forward compatibility. For #42290 Change-Id: I15e3c2bffd2046c20297b1857057d421f633098a Reviewed-on: https://go-review.googlesource.com/c/go/+/264179 Run-TryBot: Robert Findley <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> Reviewed-by: Robert Griesemer <firstname.lastname@example.org> Trust: Robert Griesemer <email@example.com> Trust: Robert Findley <firstname.lastname@example.org>
In CL 264179, some reorganization of error codes was deferred in order to minimize diffs between patch-sets. This CL reorganizes the error codes as discussed. It is a pure reordering, with no material changes other than the changing of internal const values. For #42290 Change-Id: I0e9b421a92e96b19e53039652f8de898c5255290 Reviewed-on: https://go-review.googlesource.com/c/go/+/266637 Run-TryBot: Robert Findley <email@example.com> Trust: Robert Findley <firstname.lastname@example.org> Trust: Robert Griesemer <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org> Reviewed-by: Robert Griesemer <email@example.com>
Tools often need to associate errors not with a single position, but with a span of source code. For example, gopls currently estimates diagnostic spans using heuristics to expand the positions reported by the type checker to surrounding source code. Unfortunately this is often inaccurate. This CL lays the groundwork to solve this within go/types by adding a start and end position to type checker errors. This is an experimental API, both because we are uncertain of the ideal representation for these spans and because their initial positioning is naive. In most cases this CL simply expands errors to the surrounding ast.Node being typechecked, if available. This might not be the best error span to present to the user. For these reasons the API is unexported -- gopls can read these positions using reflection, allowing us to gain experience and improve them during the next development cycle. For #42290 Change-Id: I39a04d70ea2bb2134b4d4c937f32b2ddb4456430 Reviewed-on: https://go-review.googlesource.com/c/go/+/265250 Run-TryBot: Robert Findley <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> Reviewed-by: Robert Griesemer <firstname.lastname@example.org> Trust: Robert Findley <email@example.com> Trust: Robert Griesemer <firstname.lastname@example.org>
This CL adds a copy of the internal error codes added to go/types in https://golang.org/cl/264179. In a subsequent CL, we will use these to extract the unexported error code from go/types errors via reflection. A generated String method is added to provide a human-readable code for the user. For golang/go#42290 Change-Id: I280c9b111598426dce4eef38b9979919ed590068 Reviewed-on: https://go-review.googlesource.com/c/tools/+/267939 Trust: Robert Findley <email@example.com> Run-TryBot: Robert Findley <firstname.lastname@example.org> gopls-CI: kokoro <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org> Reviewed-by: Rebecca Stambler <email@example.com>