go/src/runtime/runtime.go, branch json-isValidNumber

runtime: expose auxv for use by x/sys/cpu

2023-02-16T19:34:38Z

Updates #57336 Change-Id: I181885f59bac59360b855d3990326ea2b268bd28 Reviewed-on: https://go-review.googlesource.com/c/go/+/458256 Reviewed-by: Michael Pratt TryBot-Result: Gopher Robot Auto-Submit: Brad Fitzpatrick Reviewed-by: Austin Clements Run-TryBot: Brad Fitzpatrick Reviewed-by: Ian Lance Taylor

internal/godebug: export non-default-behavior counters in runtime/metrics

2023-01-19T22:26:43Z

Allow GODEBUG users to report how many times a setting resulted in non-default behavior. Record non-default-behaviors for all existing GODEBUGs. Also rework tests to ensure that runtime is in sync with runtime/metrics.All, and generate docs mechanically from metrics.All. For #56986. Change-Id: Iefa1213e2a5c3f19ea16cd53298c487952ef05a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/453618 TryBot-Result: Gopher Robot Auto-Submit: Russ Cox Run-TryBot: Russ Cox Reviewed-by: Michael Knyszek

runtime: replace panic(nil) with panic(new(runtime.PanicNilError))

2023-01-19T22:21:50Z

Long ago we decided that panic(nil) was too unlikely to bother making a special case for purposes of recover. Unfortunately, it has turned out not to be a special case. There are many examples of code in the Go ecosystem where an author has written panic(nil) because they want to panic and don't care about the panic value. Using panic(nil) in this case has the unfortunate behavior of making recover behave as though the goroutine isn't panicking. As a result, code like: func f() { defer func() { if err := recover(); err != nil { log.Fatalf("panicked! %v", err) } }() call1() call2() } looks like it guarantees that call2 has been run any time f returns, but that turns out not to be strictly true. If call1 does panic(nil), then f returns "successfully", having recovered the panic, but without calling call2. Instead you have to write something like: func f() { done := false defer func() { if err := recover(); !done { log.Fatalf("panicked! %v", err) } }() call1() call2() done = true } which defeats nearly the whole point of recover. No one does this, with the result that almost all uses of recover are subtly broken. One specific broken use along these lines is in net/http, which recovers from panics in handlers and sends back an HTTP error. Users discovered in the early days of Go that panic(nil) was a convenient way to jump out of a handler up to the serving loop without sending back an HTTP error. This was a bug, not a feature. Go 1.8 added panic(http.ErrAbortHandler) as a better way to access the feature. Any lingering code that uses panic(nil) to abort an HTTP handler without a failure message should be changed to use http.ErrAbortHandler. Programs that need the old, unintended behavior from net/http or other packages can set GODEBUG=panicnil=1 to stop the run-time error. Uses of recover that want to detect panic(nil) in new programs can check for recover returning a value of type *runtime.PanicNilError. Because the new GODEBUG is used inside the runtime, we can't import internal/godebug, so there is some new machinery to cross-connect those in this CL, to allow a mutable GODEBUG setting. That won't be necessary if we add any other mutable GODEBUG settings in the future. The CL also corrects the handling of defaulted GODEBUG values in the runtime, for #56986. Fixes #25448. Change-Id: I2b39c7e83e4f7aa308777dabf2edae54773e03f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/461956 Reviewed-by: Robert Griesemer Run-TryBot: Russ Cox TryBot-Result: Gopher Robot Auto-Submit: Russ Cox

internal/godebug: define more efficient API

2022-11-14T15:19:57Z

We have been expanding our use of GODEBUG for compatibility, and the current implementation forces a tradeoff between freshness and efficiency. It parses the environment variable in full each time it is called, which is expensive. But if clients cache the result, they won't respond to run-time GODEBUG changes, as happened with x509sha1 (#56436). This CL changes the GODEBUG API to provide efficient, up-to-date results. Instead of a single Get function, New returns a *godebug.Setting that itself has a Get method. Clients can save the result of New, which is no more expensive than errors.New, in a global variable, and then call that variable's Get method to get the value. Get costs only two atomic loads in the case where the variable hasn't changed since the last call. Unfortunately, these changes do require importing sync from godebug, which will mean that sync itself will never be able to use a GODEBUG setting. That doesn't seem like such a hardship. If it was really necessary, the runtime could pass a setting to package sync itself at startup, with the caveat that that setting, like the ones used by runtime itself, would not respond to run-time GODEBUG changes. Change-Id: I99a3acfa24fb2a692610af26a5d14bbc62c966ac Reviewed-on: https://go-review.googlesource.com/c/go/+/449504 Run-TryBot: Russ Cox Auto-Submit: Russ Cox Reviewed-by: Michael Knyszek Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot

runtime: consolidate some low-level error reporting

2022-11-10T18:51:20Z

Use a single writeErrStr function. Avoid using global variables. Use a single version of some error messages rather than duplicating the messages in OS-specific files. Change-Id: If259fbe78faf797f0a21337d14472160ca03efa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/447055 Run-TryBot: Ian Lance Taylor Run-TryBot: Ian Lance Taylor TryBot-Result: Gopher Robot Reviewed-by: Ian Lance Taylor Auto-Submit: Ian Lance Taylor Reviewed-by: Michael Knyszek

internal/godebug: remove dependency on os

2022-10-18T14:49:44Z

The immediate reason is that we want to use godebug from math/rand, and math/rand importing godebug importing os causes an import cycle in package testing. More generally, the new approach to backward compatibility outlined in discussion #55090 will require using this package from other similarly sensitive places, perhaps even package os itself. Best to remove all dependencies. Preparation for #54880. Change-Id: Ia01657a2d90e707a8121a336c9db3b7247c0198f Reviewed-on: https://go-review.googlesource.com/c/go/+/439418 Auto-Submit: Russ Cox Run-TryBot: Russ Cox Reviewed-by: Austin Clements Reviewed-by: Ian Lance Taylor TryBot-Result: Gopher Robot

runtime: convert ticksType.val to atomic type

2022-08-23T20:00:03Z

Updates #53821 Change-Id: Ia0c58d7e7e11a1b52bbb7c19ebbb131e3eea5314 Reviewed-on: https://go-review.googlesource.com/c/go/+/424926 Reviewed-by: Michael Knyszek Run-TryBot: Cuong Manh Le Auto-Submit: Cuong Manh Le TryBot-Result: Gopher Robot Reviewed-by: Michael Pratt

runtime: generate the lock ranking from a DAG description

2022-08-04T15:31:44Z

Currently, the runtime lock rank graph is maintained manually in a large set of arrays that give the partial order and a manual topological sort of this partial order. Any changes to the rank graph are difficult to reason about and hard to review, as well as likely to cause merge conflicts. Furthermore, because the partial order is manually maintained, it's not actually transitively closed (though it's close), meaning there are many cases where rank a can be acquired before b and b before c, but a cannot be acquired before c. While this isn't technically wrong, it's very strange in the context of lock ordering. Replace all of this with a much more compact, readable, and maintainable description of the rank graph written in the internal/dag graph language. We statically generate the runtime structures from this description, which has the advantage that the parser doesn't have to run during runtime initialization and the structures can live in static data where they can be accessed from any point during runtime init. The current description was automatically generated from the existing partial order, combined with a transitive reduction. This ensures it's correct, but it could use some manual messaging to call out the logical layers and add some structure. We do lose the ad hoc string names of the lock ranks in this translation, which could mostly be derived from the rank constant names, but not always. I may bring those back but in a more uniform way. We no longer need the tests in lockrank_test.go because they were checking that we manually maintained the structures correctly. Fixes #53789. Change-Id: I54451d561b22e61150aff7e9b8602ba9737e1b9b Reviewed-on: https://go-review.googlesource.com/c/go/+/418715 Run-TryBot: Austin Clements Reviewed-by: Michael Pratt TryBot-Result: Gopher Robot

runtime: test alignment of fields targeted by 64-bit atomics

2022-05-19T20:10:40Z

Make sure that all the targets of 64-bit atomic operations are actually aligned to 8 bytes. This has been a source of bugs on 32-bit systems. (e.g. CL 399754) The strategy is to have a simple test that just checks the alignment of some explicitly listed fields and global variables. Then there's a more complicated test that makes sure the list used in the simple test is exhaustive. That test has some limitations, but it should catch most cases, particularly new uses of atomic operations on new or existing fields. Unlike a runtime assert, this check is free and will catch accesses that occur even in very unlikely code paths. Change-Id: I25ac78df471ac33b57cb91375bd8453d6ce2814f Reviewed-on: https://go-review.googlesource.com/c/go/+/407034 Run-TryBot: Keith Randall Reviewed-by: Michael Knyszek Reviewed-by: David Chase TryBot-Result: Gopher Robot

syscall: make Exit call runtime.exit

2017-09-27T01:10:05Z

syscall.Exit and runtime.exit do the same thing. Why duplicate code? CL 45115 fixed bug where windows runtime.exit was correct, but syscall.Exit was broken. So CL 45115 fixed windows syscall.Exit by calling runtime.exit. Austin suggested that all OSes should do the same, and this CL implements his idea. While making changes, I discovered that nacl syscall.Exit returned error func Exit(code int) (err error) and I changed it into func Exit(code int) like all other OSes. I assumed it was a mistake and it is OK to do because cmd/api does not complain about it. Also I changed plan9 runtime.exit to accept int32 just like all other OSes do. Change-Id: I12f6022ad81406566cf9befcc6edc382eebd413b Reviewed-on: https://go-review.googlesource.com/66170 TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor Reviewed-by: Austin Clements Reviewed-by: David du Colombier <0intro@gmail.com>