fix: add wrapper for osfile.Truncate for TinyGo 0.33

[deadprogram]

This PR adds a wrapper for the osfile Truncate() functions to restore ability to build Wazero on bare metal using TinyGo 0.33

UPDATE: I have added a second commit to this PR that adds back the TinyGo 0.33 to CI, which also should demonstrate that this fix does what it is supposed to.

[evacchi]

I think this should be fine @mathetake @ncruces any comments?

[achille-roussel]

@deadprogram is the absence of a Truncate method on *os.File by design in Tinygo?

[deadprogram]

I think that it is one of the various file APIs that do not have any way to be resolved when running baremetal without any file system. Similar to what is already being done in code such as https://github.com/tetratelabs/wazero/blob/main/internal/sysfs/datasync_tinygo.go

[ncruces]

I think that it is one of the various file APIs that do not have any way to be resolved when running baremetal without any file system. Similar to what is already being done in code such as https://github.com/tetratelabs/wazero/blob/main/internal/sysfs/datasync_tinygo.go

Well, no. It's not like datasync, as that's a Linux system call. Arguably the TinyGo fall back for that one is wrong, because the appropriate fallback is to call File.Sync.

I wonder, though, why isn't the fallback for Truncate not making sense on devices without a filesystem, to return ENOSYS from TinyGo? Why should every user of TinyGo work around this? Isn't this tree shaked if unused, and a fallback required otherwise?

[mathetake]

Please fix this in TinyGo and not by adding some workaround here.

[mathetake]

Please fix this in TinyGo and not by adding some workaround here.

[mathetake]

What you are trying to add here is like "We introduced a breaking change/bug in TinyGo 0.33, so please adda a workaround in wazero", and to be honest, that's not right at all. I will NEVER accept this.

[mathetake]

And note thatwe clearly stated multiple times that interpreter is not the scope of this project, and let alone compiling support with TinyGo. When introduced the CI job, we said it's best effort and the last CI failure was the last straw. We are no longer trying to support TinyGo as a compilation target, which is not a goal of this project in the first place.

[ncruces]

I honestly think it's reasonable for us to have fallbacks for all syscall stuff, and put a reasonable effort to have the interpreter work with a current Go version standard library (latest minus 2, as per the support policy), no trickery, no unportable/undefined unsafe stuff, etc.

I personally put in a moderate (small, actually) amount of effort to support z/OS, for instance (a big endian platform that's not supported out of the box by Go, but which has a toolchain, etc). It almost worked out-of-the-box, and it passed all wazero tests, and all SQLite tests.

But it doesn't make sense for us to add workarounds for the standard library being broken on our end.

If this is interesting to you, CI can be setup on your end; it doesn't need to break us moving forward.

And I guess compatibility fixes that have the interpreter work with the Go standard library will have my upvote. But not this.

[deadprogram]

Just to be clear: this was an attempt to address compiling Wazero using TinyGo for embedded targets, not to address using a WASM module compiled using TinyGo with wazero as host on a full OS.

In any case, no problem. Thanks for everyone's feedback.