go/types: factor out some methods that compute a single error

In order to generate more accurate or informative error messages from
the type checker, it can be helpful to interpret error messages in
context. This is currently achieved in a number of ways:

 + Return a boolean value, and then reverse-engineer the error at the
   callsite (as in representable->representableConst).
 + Return a value causing the error (as in Checker.missingMethod), and
   add the error at the callsite.
 + Pass a "reason" string pointer to capture the error (as in
   Checker.assignableTo), and add the error at the callsite.
 + Pass a "context" string pointer, and use this when writing errors in
   the delegated method.

In all cases, it is the responsibility of whatever code calls
Checker.error* to set the operand mode to invalid.

These methods are used as appropriate, depending on whether multiple
errors are generated, whether additional context is needed, and whether
the mere presence of an error needs to be interpreted at the callsite.
However, this practice has some downsides: the plurality of error
handling techniques can be a barrier to readability and composability.

In this CL, we introduce Yet Another Pattern, with the hope that it can
replace some or all of the existing techniques: factor out side-effect
free functions that evaluate a single error, and add helpers for
recording this error in the Checker.

As a proof of concept this is done for Checker.representable and
Checker.convertUntyped. If the general pattern does not seem appropriate
for replacing some or all of the error-handling techniques listed above,
we should revert to an established technique.

Some internal error APIs are refactored to operate on an error, rather
than a types.Error, with internal error metadata extracted using
errors.As. This seemed to have negligible impact on performance, but we
should be careful about actually wrapping errors: I expect that many
users will expect err to be a types.Error.

Change-Id: Ic5c6edcdc02768cd84e04638fad648934bcf3c17
Reviewed-on: https://go-review.googlesource.com/c/go/+/242082
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2 files changed
tree: 8ee8fa5cc3d0c8bc92b6074322a35d114d10213a
  1. .gitattributes
  2. .github/
  3. .gitignore
  9. README.md
  10. SECURITY.md
  11. api/
  12. doc/
  13. favicon.ico
  14. lib/
  15. misc/
  16. robots.txt
  17. src/
  18. test/

The Go Programming Language

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

Gopher image Gopher image by Renee French, licensed under Creative Commons 3.0 Attributions license.

Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.

Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.

Download and Install

Binary Distributions

Official binary distributions are available at https://golang.org/dl/.

After downloading a binary release, visit https://golang.org/doc/install or load doc/install.html in your web browser for installation instructions.

Install From Source

If a binary distribution is not available for your combination of operating system and architecture, visit https://golang.org/doc/install/source or load doc/install-source.html in your web browser for source installation instructions.


Go is the work of thousands of contributors. We appreciate your help!

To contribute, please read the contribution guidelines: https://golang.org/doc/contribute.html

Note that the Go project uses the issue tracker for bug reports and proposals only. See https://golang.org/wiki/Questions for a list of places to ask questions about the Go language.