Bring back fmt.Stringer implementation for interpreter.Value #969
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In #906 we refactored the string formatting of interpreter values so it supports recursive structures (due to references). This PR then removed support for
fmt.Stringer
.This is problematic, because many parts of the code, most prominently errors, rely on values implementing
String()
implicitly by usingfmt
functions with the%s
format directive.Now that support for
String()
was removed from values, error messages were rendered incorrectly.Most notably, address values are just byte slices, and Go's default formatting, which will be used when the value does not implement
fmt.Stringer
, will encode the bytes directly as-is. For example, the byte slice[]byte{0x1, 0x2}
results in the Go string"\x01\x02"
– which is not valid UTF-8.This results in problems in downstream dependencies like flow-go, which requires strings to be valid UTF-8 (e.g. for Protocol Buffer encoding).
Bringing back support for
fmt.Stringer
thus also fixes many error messages that are currently incorrectly formatted.master
branchFiles changed
in the Github PR explorer