aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/rangefunc/rangefunc_test.go
AgeCommit message (Collapse)Author
2024-11-13cmd/compile: change status of "bad iterator" panicDavid Chase
Execution of the loop body previously either terminated the iteration (returned false because of a break, goto, or return) or actually panicked. The check against abi.RF_READY ensures that the body can no longer run and also panics. This CL in addition transitions the loop state to abi.RF_PANIC so that if this already badly-behaved iterator defer-recovers this panic, then the exit check at the loop context will catch the problem and panic there. Previously, panics triggered by attempted execution of a no-longer active loop would not trigger a panic at the loop context if they were defer-recovered. Change-Id: Ieeed2fafd0d65edb66098dc27dc9ae8c1e6bcc8c Reviewed-on: https://go-review.googlesource.com/c/go/+/625455 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Tim King <taking@google.com>
2024-10-26cmd/compile: use a non-fragile test for "does f contain closure c?"David Chase
The old test relied on naming conventions. The new test uses an explicit parent pointer chain initialized when the closures are created (in the same place that the names used in the older fragile test were assigned). Fixes #70035. Change-Id: Ie834103c7096e4505faaff3bed1fc6e918a21211 Reviewed-on: https://go-review.googlesource.com/c/go/+/622656 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-07-30cmd/compile: verify that rangefunc assigning to no vars worksDavid Chase
This adds a test for for range seq2rangefunc { ... } and for onevar := range seq2rangefunc { ... } For #65236. Change-Id: I083f8e4c19eb4ba0d6024d5314ac29d941141778 Reviewed-on: https://go-review.googlesource.com/c/go/+/596135 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-06-03all: make function comments match function namescuishuang
Change-Id: Ideb9ef00e7bc660b005fc080973fd9f3d36c5a1f Reviewed-on: https://go-review.googlesource.com/c/go/+/589536 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2024-05-22runtime,cmd/compile: fix wording of rangefunc panic messagesDavid Chase
Change-Id: I883e7b6554646f32ad44e4ea6583440c33f02b84 Reviewed-on: https://go-review.googlesource.com/c/go/+/587595 Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-05-21cmd/compile: for rangefunc, add checks and tests, fix panic interactionsDavid Chase
Modify rangefunc #next protocol to make it more robust Extra-terrible nests of rangefunc iterators caused the prior implementation to misbehave non-locally (in outer loops). Add more rangefunc exit flag tests, parallel and tricky This tests the assertion that a rangefunc iterator running in parallel can trigger the race detector if any of the parallel goroutines attempts an early exit. It also verifies that if everything else is carefully written, that it does NOT trigger the race detector if all the parts run time completion. Another test tries to rerun a yield function within a loop, so that any per-line shared checking would be fooled. Added all the use-of-body/yield-function checking. These checks handle pathological cases that would cause rangefunc for loops to behave in surprising ways (compared to "regular" for loops). For example, a rangefunc iterator might defer-recover a panic thrown in the syntactic body of a loop; this notices the fault and panics with an explanation Modified closure naming to ID rangefunc bodies Add a "-range<N>" suffix to the name of any closure generated for a rangefunc loop body, as provided in Alessandro Arzilli's CL (which is merged into this one). Fix return values for panicky range functions This removes the delayed implementation of "return x" by ensuring that return values (in rangefunc-return-containing functions) always have names and translating the "return x" into "#rv1 = x" where #rv1 is the synthesized name of the first result. Updates #61405. Change-Id: I933299ecce04ceabcf1c0c2de8e610b2ecd1cfd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/584596 Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Tim King <taking@google.com>
2023-11-15cmd/compile: check for iteration after range func loop exitDavid Chase
When this happens, panic. This is a revised version of a check that used #next, where this one instead uses a per-loop #exit flag, and catches more problematic iterators. Updates #56413. Updates #61405. Change-Id: I6574f754e475bb67b9236b4f6c25979089f9b629 Reviewed-on: https://go-review.googlesource.com/c/go/+/540263 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>