-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: pinner.Pin doesn't panic when it says it will [1.21 backport] #63768
Comments
This was prompted by the desire to pin channel values in https://go.dev/cl/528796. Note that channels are, to my knowledge, the only Go type that cannot be allocated by either calling |
It reads like an oversight in the documentation, though it is also unclear to me what C code would do with a pinned channel or map. |
CC @mknyszek especially. |
Huh! Yeah, it looks like this is probably fixed at head as a result of #62356. 🙃 |
In that case, I guess this is a bug affecting only Go 1.21. (Leaving open for the runtime folks to decide whether it's worth backporting some kind of fix for compatibility.) |
We only usually backport fixes for regressions, so I'm inclined to leave this one be. |
Perhaps this is a go1.21 documention issue that should be written as The argument must be a pointer of any type or an unsafe.Pointer. |
Change https://go.dev/cl/553395 mentions this issue: |
See https://go.dev/wiki/MinorReleases, I think can repair go1.21 document. |
@bcmills Could you please add [1.21 backport] after the title of this issue? |
Done. |
Sorry for not replying here. @bcmills I think you're right that we shouldn't explicitly say anything panics necessarily as part of the API. We should just drop the problematic part of the documentation. (EDIT: Which it looks like we do on tip, as noted above, and we should backport that too.) I do also think we should consider:
I will file a proposal for the third bullet point. EDIT: Filed #65286. This should hopefully allow simplifying usage of the pinner API slightly, and should slightly simplify the cgo pointer passing rules. |
Fixes #63768 Change-Id: I01a9bb8f9af22a6b3f6534d431e3ea623875ed48 GitHub-Last-Rev: 7c5dd4e GitHub-Pull-Request: #64920 Reviewed-on: https://go-review.googlesource.com/c/go/+/553395 Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Closed by merging 916e6cd to release-branch.go1.21. |
The documentation for
runtime.Pinner.Pin
currently says:However, it does not always do so today.
A channel, map, or slice value can be constructed by calling
make
, which does not involve a call tonew
, nor a composite literal, nor the address of a local variable. Empirically,Pin
does not panic when called on such an object (https://go.dev/play/p/q_iyNHJduRf).It isn't clear to me whether this is a mistake in the documentation (a valid case that was omitted from the doc comment), or a bug in the implementation (
Pin
failing to panic for an unsupported address).At a higher level, it seems to me that it is basically always a mistake for a doc comment to state that something will panic for an unsupported input, since that makes it an incompatible change to ever add support for such an input. (It would be better for
Pin
not to promise anything about what happens for such an input, but to panic anyway as a debugging aid to the user.)The text was updated successfully, but these errors were encountered: