some WASI tests are disabled due to using cwd

[andrewrk]

zig/lib/std/cache_hash.zig

Lines 537 to 540 in 49f3def

	if (std.Target.current.os.tag == .wasi) {
	// https://github.com/ziglang/zig/issues/5437
	return error.SkipZigTest;
	}

(there are several more instances in this file)

WASI is capable of passing these tests if we improve the cache hash API to use directory handles and somehow avoid using absolute paths. I'm not sure how to accomplish that, however, it's worth looking into. It does look like it would be possible to implement realpathat on Linux. I wonder if it is possible to implement realpathat on other operating systems.

[kubkon]

I can't speak for all OSes, but in Wasmtime on Windows, what we do to effectively emulate realpathat (all path_ WASI syscalls are of that form effectively) is:

1. call to GetFinalPathNameByHandleW to get the canonicalised path of some opened Windows handle
2. concatenate that path with the relative path to obtain the absolute path to some resource

I'd venture a guess that if a target OS is (relatively) up-to-date with POSIX, then they should expose relevenat _at syscalls for us to make use of. For Windows, and any other OS that doesn't conform to POSIX, we could use the trick outlined above. Thoughts?

[andrewrk]

I think ultimately this comes down to reworking the API to not depend on absolute paths. I think that is worth investigating but I do not know how to solve it yet. The main problem to solve is that we have to encode paths into a file, and then later open that file and then be able to stat and read the named paths. Maybe this could be accomplished by having the relative path directory handle provided as part of the addFile API.

This is the same problem as making the cache system resilient (retaining cache hits ) when a project directory is moved, which should be possible in theory because the zig-cache directory is local to the project folder.

Another step towards solving this would probably be differentiation of the use cases of zig id which needs to open absolute paths of the zig binary's own dynamic libraries using a global zig-cache directory, and project-local caching.

[kubkon]

Sounds good! I'll be happy to have a look and help out with this endeavour. Oh, and if I understand it right, this would potentially open us up a road to having Zig itself cross-compiled to WASI and the compiler run inside a VM such as Wasmtime which I reckon is pretty cool in and of itself!