Commit 99339dd4 authored by Austin Clements's avatar Austin Clements

runtime: weaken claim about SetFinalizer panicking

Currently the SetFinalizer documentation makes a strong claim that
SetFinalizer will panic if the pointer is not to an object allocated
by calling new, to a composite literal, or to a local variable. This
is not true. For example, it doesn't panic when passed the address of
a package-level variable. Nor can we practically make it true. For
example, we can't distinguish between passing a pointer to a composite
literal and passing a pointer to its first field.

Hence, weaken the guarantee to say that it "may" panic.

Updates #17311. (Might fix it, depending on what we want to do with
package-level variables.)

Change-Id: I1c68ea9d0a5bbd3dd1b7ce329d92b0f05e2e0877
Reviewed-on: https://go-review.googlesource.com/30137Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
parent 22a2bdfe
...@@ -231,7 +231,7 @@ func runfinq() { ...@@ -231,7 +231,7 @@ func runfinq() {
// address of a local variable. // address of a local variable.
// The argument finalizer must be a function that takes a single argument // The argument finalizer must be a function that takes a single argument
// to which obj's type can be assigned, and can have arbitrary ignored return // to which obj's type can be assigned, and can have arbitrary ignored return
// values. If either of these is not true, SetFinalizer aborts the // values. If either of these is not true, SetFinalizer may abort the
// program. // program.
// //
// Finalizers are run in dependency order: if A points at B, both have // Finalizers are run in dependency order: if A points at B, both have
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment