build: makes CI choose latest Go 1.18.x

[codefromthecrypt]

No description provided.

[aykevl]

LGTM. Actually something I wanted to do a while ago but never got around doing it.

[aykevl]

The failure here looks suspiciously like the one I saw when I tried Go 1.19. I suspect a bugfix causes the test to fail. I'll need to investigate this.

[aykevl]

Looks like this is caused by golang/go@315e80d. Specifically, it is a stack overflow. I suggest removing io/fs from the tested packages because it requires a stack that's just far too large for TinyGo to support.

@dgryski @dkegel-fastly @deadprogram opinions on this removal?

[dgryski]

SGTM. We want to keep CI passing.

[deadprogram]

tinygo-org/tinyfs#6 where @bgould mentions wanting to use this package for tinyfs.

[dankegel]

Can we raise the stack size on Linux/Mac/windows and keep testing Io/fs there?

[aykevl]

It starts to work at 6MB on linux/amd64, which to me seems like an unreasonably large stack size per goroutine. Remember that TinyGo doesn't support growing the goroutine stack.

[dkegel-fastly]

How about adding a stack size commandline option? Then we could keep testing io/fs without burdening the world with big stacks...

[aykevl]

How about adding a stack size commandline option?

Yeah, sounds reasonable: #3159
It's less clear to me how it can be integrated in the Makefile, I guess we could add a new tinygo test -stack-size=6MB io/fs command. Or we'd have to run all tests with a 6MB stack, which I'm not sure is a good idea either.
Perhaps a better solution is a way to skip just that particular test (TestCVE202230630), because it's written in a way that is incompatible with TinyGo. Not sure how to do that either.

[codefromthecrypt]

@aykevl

It's less clear to me how it can be integrated in the Makefile

could a heavy or slow tag help? It is fairly common for projects to have slow, bench or otherwise code in the makefile, just only run in CI to keep dev flow faster. ex make tinygo-test.slow

FYI I'm keeping the comments running on this topic despite not being related to go versions, as they are here anyway. If we don't come up with a way out before this merges, we should fork an issue to make sure things work smooth.

[codefromthecrypt]

I tried a workaround to help middle-ground approach.

[codefromthecrypt]

looks like a green. feel free to squash on my behalf if this is a go @deadprogram etc!

[dkegel-fastly]

LGTM!

[codefromthecrypt]

anyone has my permission to squash or obviate this with another PR if the solution isn't good enough. I'll be away for a few days.

[deadprogram]

Thanks very much for fixing this @codefromthecrypt now going to squash/merge.