Conversation
Affected lines may add `//errtrace:skip`
to opt-out of being instrumented.
This is necessary for types implementing `io.Reader`;
they must return `io.EOF`, not `fmt.Errorf("%w", io.EOF)`,
or functions like `io.ReadAll` will misbehave[^1].
[^1]: https://cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/io/io.go;l=707
| For example, if you're implementing `io.Reader`, | ||
| you need to return `io.EOF` when you reach the end of the input. | ||
| Wrapping it will cause functions like `io.ReadAll` to misbehave. |
There was a problem hiding this comment.
maybe a feature request for future, should we have a set of default opt-outs inbuilt, like don't wrap io.EOF when being returned from Read? (It's not perfect, but seems like it's never correct to wrap an EOF error from Read)
There was a problem hiding this comment.
Yeah, we can explore that if this becomes a need in the future.
Tracking in #60.
| _, ok := t.optouts[line] | ||
| return ok |
There was a problem hiding this comment.
optional: should we try to detect optouts that have no impact? we could delete(..) here if we find a match, and any optouts that remain would indicate invalid optouts?
There was a problem hiding this comment.
Makes sense. Can address in a follow up. Created #61.
Deleting won't do, though.
return a, err1, err2 //errtrace:skip
This will hit the opt-out check twice.
So we'll have to maintain a second list of opt-outs that have been used, then tally them after the file has been processed.
Affected lines may add
//errtrace:skipto opt-out of being instrumented.
This is necessary for types implementing
io.Reader;they must return
io.EOF, notfmt.Errorf("%w", io.EOF),or functions like
io.ReadAllwill misbehave1.//errtrace:skipmakes sense as the opt-out to me,but I'm open to other suggestions.
Footnotes
https://cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/io/io.go;l=707 ↩