On windows 11, "tinygo test -target wasi os" fails because wasi does not support cd .. yet

[dankegel]

With a fresh windows 11 machine and today's dev (including clang 14):

$ ~/src/tinygo/build/tinygo test -target wasi os
Returning nil error open C:\Users\dank\AppData\Local\Temp\tinygotmp1446174477/TestFd.txt147587007: file not found
Caused by:
           1: 0x63ad - runtime.nilPanic
                           at C:\Users\dank\src\tinygo\src\runtime\panic.go:32:14
           2: 0x332f5 - (*os.File).Name
           3: 0x755c5 - os_test.TestFd
                           at C:\Users\dank\src\tinygo\src\os\file_anyos_test.go:98:21

Running wasmtime os.test under procmon, I noticed something funny: temporary files being opened were at the wrong location, as if wasmtime was confused by drive letters. Building just the test by itself, then creating a writable directory C:\TMP,
then running in a CMD window, I saw that the command

wasmtime --dir=. --dir=.. --dir=..\.. --dir=/tmp --env=TMPDIR=/tmp os.test

succeeds, but the commands

wasmtime --dir=. --dir=.. --dir=..\.. --dir=c:/tmp --env=TMPDIR=c:/tmp os.test
wasmtime --dir=. --dir=.. --dir=..\.. --dir=\tmp --env=TMPDIR=\tmp os.test
wasmtime --dir=. --dir=.. --dir=..\.. --dir=c:\tmp --env=TMPDIR=c:\tmp os.test

all fail. It seems that TMPDIR must be a unix style directory... which makes sense, since wasi is unix-ish.
And since wasmtime probably does an exact compare on the dirs to grant access, it needs the unix style directory, too.

The workaround is easy as long as TMPDIR is on the default drive...

This seems like a regression; wasn't this working before? Maybe not; we haven't been running tinygo-test-wasm in ci on windows...

[dankegel]

Related: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/sources/preopens.c

[dankegel]

On today's dev, the test succeeds in isolation:

$ ~/src/tinygo/build/tinygo.exe test -target wasi -v -run 'TestFd' os
=== RUN   TestFd
--- PASS: TestFd (0.00s)
PASS
ok      os      0.144s

as does TestChdir:

$ ~/src/tinygo/build/tinygo.exe test -target wasi -v -run 'TestChdir' os
XYZZY: Run TestChdir TestChdir
=== RUN   TestChdir
--- PASS: TestChdir (0.00s)
PASS

But together, they explode:

$ ~/src/tinygo/build/tinygo.exe test -target wasi -v -run 'TestChdir|TestFd' os
Returning nil error open C:\Users\dank\AppData\Local\Temp\tinygotmp2555839111/TestFd.txt108297876: file not found
panic: runtime error: nil pointer dereference
Error: failed to run main module `C:\Users\dank\AppData\Local\Temp\tinygo32454820\main`

Caused by:
           1: 0x63ad - runtime.nilPanic
                           at C:\Users\dank\src\tinygo\src\runtime\panic.go:32:14
           2: 0x332f5 - (*os.File).Name
           3: 0x756ae - os_test.TestFd
                           at C:\Users\dank\src\tinygo\src\os\file_anyos_test.go:99:21

procmon shows the failed operation was a CreateFile on
C:\Users\dank\AppData\Local\tinygo\goroot-ddc010ecf4bb48ee8dd17b18ccbda41b3242369ab05fe19cc051875e70f76a16\src\os\Users
near the beginning of TestFd.

So it seems TestChdir is misbehaving under wasi under windows somehow, breaking TestFd.

Adding a print of the current directory at the start of TestFd shows:

XYZZY: GetWd returns /_os_test_TestChDir/.. 

Evidently chdir under wasi is vestigal, and doesn't know enough to change to the parent directory when you change to ".."

Why this only causes test failures under windows is a mystery.