`cargo test <name>` errors with "error: invalid value '<name>' for '[files]...': File does not exist"

help
1

So I have no idea what could be causing this. I've used cargo test in the past and it's worked fine.

I've tried it with both cargo --version 1.82.0, and cargo --version 1.84.1

lennart@Tumxedo:~/Desktop/sus-compiler$ cargo test fifo_use
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.06s
     Running unittests src/main.rs (target/debug/deps/sus_compiler-1b71e2b3f6ebb086)

running 2 tests
error: invalid value 'fifo_use' for '[files]...': File does not exist

For more information, try '--help'.
error: test failed, to rerun pass `--bin sus_compiler`

Caused by:
  process didn't exit successfully: `/home/lennart/Desktop/sus-compiler/target/debug/deps/sus_compiler-1b71e2b3f6ebb086 fifo_use` (exit status: 2)
note: test exited abnormally; to see the full output pass --nocapture to the harness.

Likewise, trying to run them from VSCode, by clicking "Debug" or "Run" in the editor gives me a different error:

Executing task: cargo test --package sus_compiler --bin sus_compiler --all-features -- latency::latency_algorithm::tests::minimal_fifo_use --exact --show-output 

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running unittests src/main.rs (target/debug/deps/sus_compiler-6bb83a2f9d1856c2)

running 1 test
error: unexpected argument '--exact' found

  tip: to pass '--exact' as a value, use '-- --exact'

Usage: sus_compiler-6bb83a2f9d1856c2 <files>...

For more information, try '--help'.
error: test failed, to rerun pass `-p sus_compiler --bin sus_compiler`

Caused by:
  process didn't exit successfully: `/home/lennart/Desktop/sus-compiler/target/debug/deps/sus_compiler-6bb83a2f9d1856c2 'latency::latency_algorithm::tests::minimal_fifo_use' --exact --show-output` (exit status: 2)
note: test exited abnormally; to see the full output pass --nocapture to the harness.

 *  The terminal process "cargo 'test', '--package', 'sus_compiler', '--bin', 'sus_compiler', '--all-features', '--', 'latency::latency_algorithm::tests::minimal_fifo_use', '--exact', '--show-output'" failed to launch (exit code: 2). 
 *  Terminal will be reused by tasks, press any key to close it.

So there are two tests that match fifo_use:
latency::latency_algorithm::tests::fifo_use and latency::latency_algorithm::tests::minimal_fifo_use

Weirdly, it does find them, yet still errors saying fifo_use is an invalid value for [Files...]?

I've been able to continue working for the time being by commenting out all other tests

3

Do you have any functions that read std::env::args()? This would happen if you read std::env::args() from inside test code expecting them to be the args to your compiler. You should do that only in main(), and other functions should take function parameters instead of reading the process-global args.

5 Likes
4

Nicely spotted. I believe it is the solve_latencies function accessing a global configuration singleton that reads std::env::args_os().

2 Likes
5

I am incredibly impressed. Indeed, that was the issue.

6

I guess I'll explicitly put a #[cfg(not(test))] above that line.

7

I strongly recommend that you not do that; both of these things make programs harder to understand and maintain:

  • making different test and non-test code paths, and
  • reading global configuration

Instead, as I said in my previous message, you should pass configuration down as function parameters (or struct fields).

2 Likes
8

Thing is, this is a simple debug flag meant to easily extract failing problem instances encountered while running in production and convert them to #[test] instances. It was never meant to be used with tests.

I can see the merit of having one centralized place where the args are parsed near main, but passing a config struct down to every single caller that could want it is infeasible. Especially because most weird places it is used in are for undocumented flags to aid in debugging.

I will however, also put a panic in pub fn config() -> &'static ConfigStruct if it's ever called from a build with #[cfg(test)] enabled. Such that this weird error won't come back to haunt me in the future.

9

That seems like a reasonable compromise, but what I would do myself in that situation is put the configuration in a global static OnceLock, and then have main() read flags and write that configuration. That way, you can still run the same code from tests, if needed.

10

Oh, I hadn't heard of OnceLock before, that is a much better solution indeed. Thank you :grin: