testing: implement {Skip,Fail}Now

[leongross]

PR #4623 implements runtime.GoExit() with which we can improve the testing package and align it more to upstream testing behavior https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/testing/testing.go;l=1150

[deadprogram]

Thanks for the improvement @leongross now merging.

[leongross]

@deadprogram thanks for reviewing and merging.

[aykevl]

@leongross how did you test this? Because when I try to run a trivial test like this:

package main_test

import "testing"

func TestFoo(t *testing.T) {
        t.Skip("testing skip")
        println("after skip")
}

It crashes with an error like this:

$ GOARCH=amd64 build/tinygo test -c -o test.exe ./tmp/test
$ ./test.exe
panic: runtime error at 0x00000000004062e7: deadlocked: no event source

(Currently testing in a Windows ARM VM, I can later test the same thing on Linux for example).

[aykevl]

This is also happening on MacOS:

$ tinygo test -v ./tmp/test
=== RUN   TestFoo
    testing skip
panic: runtime error at 0x00000001029ddf24: deadlocked: no event source
FAIL	github.com/tinygo-org/tinygo/tmp/test	0.186s

[leongross]

@aykevl I investigated this error and found that it has to do with the signal handling in the runtime_unix.go in the waitForEvents function. If hasSignals is false, this deadlock occurs. Iirc, this variable is set to true when we enable a single using the signal_enable function. When the signal_enable function is not called, the hasSignals variable is false by default, and then this panic occurs.

The waitForSignals function is called in the scheduler function where it then panics on the first call to it.

[aykevl]

@leongross that's unrelated. The problem is that it exits the main goroutine (at least that's what I think happens) so there's no goroutine left. The reason it deadlocks instead of emitting a runtime panic when a signal is enabled, is because theoretically a signal might arrive which might unblock a blocked goroutine. But then you just end up with a deadlocked program instead of a runtime panic - not an improvement.

I think the only way to implement Skip etc is by running each test in a separate goroutine, which would mean runtime.Goexit() indeed exits just that test instead of the whole program. But starting a new goroutine for each test is expensive, especially on embedded. So there's a tradeoff here.

In any case, next time please include a test to show that it works :)
There are a bunch of tests in testdata/testing.go where a t.Skip() test could be added.