Add TestEnv for Nextest support

[Firestar99]

• new TestEnv ensures tests get separate cache dirs so they don't clobber themselves if run in parallel
• cargo nextest run now works
• partial cherry-pick from Divide project into library and binary parts, round 2 #117 refactored that part later
• update rust-gpu in shader template (in that old version spirv-tools fails to build, see rust-gpu master / spirv-tools fails to build on latest nix rust-gpu#370)

[Firestar99]

The template's spirv-std update included Rust-GPU/rust-gpu#380, which forces glam to 0.30.8+. But specifying that glam version breaks all older rustc_codegen_spirv versions, see 0.8.0 and 0.9.0 failing. So I switched to using the reexported glam from spirv-std.

[tombh]

Our main::cache_dir() function already has a clause for tests:

    Ok(if cfg!(test) {
        let thread_id = std::thread::current().id();
        let id = format!("{thread_id:?}").replace('(', "-").replace(')', "");
        dir.join("tests").join(id)
    } else {
        dir
    })

So either we need to delete that or, what about if we pass the function the tempdirpath, like cache_dir(Option<PathBuf>)? I think it'd be nice to still be getting test coverage for that function.

But now I'm wondering about tempdir's default use of Drop to automate the directory removal. What if shader_crate_test_path() returned tempfile::TempDir? Would that mean we don't need the thread-local TEMPDIR nor even the tests_teardown?

[tuguzT]

Our main::cache_dir() function already has a clause for tests:

    Ok(if cfg!(test) {
        let thread_id = std::thread::current().id();
        let id = format!("{thread_id:?}").replace('(', "-").replace(')', "");
        dir.join("tests").join(id)
    } else {
        dir
    })

The main reason behind removing this condition and replacing it with tempfile::Tempdir inside of #117 is to be able to move this function out of CLI crate, because cfg!(test) is not portable across crates.

This is because of the following neat reason: when the parent crate has this cfg set in its own tests, child crate (which is dependent on the parent) does not have this cfg set, and so cache dir is always the same for all its tests (which is just dir).

So either we need to delete that or, what about if we pass the function the tempdirpath, like cache_dir(Option)? I think it'd be nice to still be getting test coverage for that function.

I really hope this hack (due to the lack of tempfile at the moment of writing this?) would be removed.
If this is really needed to create child directory inside of cache one, one could use TempDir::with_prefix_in.

Also we could provide an optional path argument for cargo-gpu command (or some builder as in my PR) to specify where to cache codegen backend files.

But now I'm wondering about tempdir's default use of Drop to automate the directory removal. What if shader_crate_test_path() returned tempfile::TempDir? Would that mean we don't need the thread-local TEMPDIR nor even the tests_teardown?

I haven't thought about that in my PR: I've just tried to preserve testing logic as much as possible (at that moment).
I think this could be beneficial to just return tempfile::TempDir (and maybe close it manually).

[Firestar99]

Changed the entire testing infrastructure to use the new TestEnv:

/// TestEnv sets up a temp dir in ./target/cargo-gpu-test/ that is used as the cache dir. Not initializing a
/// TestEnv and asking for the cache dir will panic, to ensure you set it up. Calling [Self::setup_shader_crate]
/// or [Self::setup_shader_crate_with_cargo_toml] will copy the shader_crate_template into the temp dir and return
/// you the path to it, so each test now has it's unique copy and won't race to change the template in the repo.
/// Dropping TestEnv will clean up the dir, except when panic unwinding, so you can debug failures.

Please rereview!

[tombh]

Wow, nice work. I really like the check for TestEnv setup in test_cache_dir(). And that self.0.disable_cleanup(true); on panic is very cool.

My only question is whether thread_local! works for both cargo test and cargo nextest? I think so, but just wanted to check. If cargo test runs tests per process (as opposed to cargo nextest's per thread), then by default each test still gets a unique TESTDIR right?

[Firestar99]

Afaik cargo test runs each test in a separate thread, but does so sequentially. cargo nextest spawns a new process for each test, and let's them run in parallel. So in theory, you could even replace the thread_local! with a static global RefCell and it should still work, and it would "fix" any multithreading we may do in the future (aka. most likely never).

[Firestar99]

I may have another idea on how to fix spirv-std 0.9.0 & 0.8.0, but I'd like this merged first to prevent potential conflicts