syscall: add DLLError.Unwrap() method [freeze exception]

[zx2c4]

These older structs embed a wrapped error. But because they're old, they haven't defined an Unwrap() method. We should do this, so that users can check for issues such as if errors.Is(err, windows.ERROR_PROC_NOT_FOUND) { ... }, which is becoming more important as Microsoft keeps adding APIs.

[gopherbot]

Change https://golang.org/cl/269761 mentions this issue: syscall: add DLLError.Unwrap function

[gopherbot]

Change https://golang.org/cl/269937 mentions this issue: windows: add DLLError.Unwrap function

[zx2c4]

cc @alexbrainman

[zx2c4]

Changing the title, as things are now handled with x/sys/windows.

[alexbrainman]

@zx2c4 thank you for creating this issue.

I adjusted your issue title so it looks like proposal

https://github.com/golang/proposal#the-proposal-process

I also fiddled with the labels. Hopefully I did correct thing.

Now we wait for proposal decision. Even if this proposal is accepted, I doubt we will be able to implement this until Go 1.16 is released.

Alex

[rsc]

This seems OK and it would be better to be consistent with x/sys.
It is also consistent with our adding Unwrap to every error implementation that wraps another error.
I'm not sure how we missed this one to start with.

Looking in the API files, I see these remaining without Unwrap methods:

go1.txt:230:pkg compress/flate, type ReadError struct, Err error
go1.txt:236:pkg compress/flate, type WriteError struct, Err error

And those are marked "Deprecated, no longer returned".
So somehow we missed only DLLError (and maybe x509.SystemRootsError, which was recently fixed).

Let's fix it.

[rsc]

Because it is trivial and consistent with everything else, we can just approve this. Accepted.

[zx2c4]

Great. I'll submit https://go-review.googlesource.com/c/go/+/269761/ whenever you want to +2 it.

[alexbrainman]

@rsc @golang/release

There is https://go-review.googlesource.com/c/go/+/269761/ that implements this change. The CL was submitted after Go 1.16 freeze started. I propose we submit the CL now for Go 1.16.

The change is trivial.

And according to @rsc #42584 (comment) the change was somehow missed. Let's fix this problem in Go 1.16 rather than delaying it for Go 1.17.

What do you think?

Alex

[dmitshur]

@alexbrainman Thanks for making this freeze exception request and providing a rationale.

I am approving this for Go 1.16. The change is trivial and should not add significant delay or increase risk for the release. (It's also easy to revert if we learn of serious problems that cannot be resolved in time.)