cmd/errtrace: Built-in list of exclusions

[abhinav]

From:

          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`)

Originally posted by @prashantv in #57 (comment)

---

We should consider a built-in list of ignores.
These will be pretty simplistic since we don't use type information (yet).
We already have an exclusion for Unwrap() error methods.

This issue is to track both, the feature and what should be in the exclusions initially:

• io.EOF returned from a Read() (int, error) method

[Nico-Hab]

I just ran into this and wondered why IO code stopped functioning with my Readers, after running the CLI instrumentation tool. This would be very helpful, even if it's not perfect

[blampe]

Excluding explicit io.EOF would be a big improvement, but I assume wrapped readers could still break? Could we handle this case if type info was available?

func (b *gzippedBlob) Read(p []byte) (int, error) {
    return b.gz.Read(p)
}

[prashantv]

Wrapped readers make it pretty tricky since there isn't necessarily any reference to io or io.EOF in those cases.

While we were initially thinking of exclusions at compile-time, I wonder if we should also consider runtime exclusions. The compile-time code can instrument all calls, but the Wrap method could check against a runtime list and return the original error in those cases.