The current code for --runtool can interact in platform-specific ways with --test-run-directory because it uses current_dir in combination with potentially relative paths which has platform-specific behavior.

This also causes issues with Cargo, since in some cases it makes the path relative to the package in a workspace instead of the workspace itself. This means that in a workspace, it can be difficult or impossible to use a relative path for the --runtool since it would change for every package.

Reproduction:

1. mkdir foo
2. cd foo
3. mkdir tool
4. Create a runtool:

   cat <<'EOF' > tool/echo.rs
   fn main() { eprintln!("{:?}", std::env::args().collect::<Vec<_>>()); }
   EOF
   

5. rustc --out-dir tool tool/echo.rs
6. mkdir subdir
7. Create a test file:

   cat <<'EOF' > subdir/example.rs
   /// ```
   /// example::foo();
   /// ```
   pub fn foo() {}
   EOF
   

8. rustc --crate-type=rlib subdir/example.rs
9. Verify test works: rustdoc --edition=2021 -L . --test subdir/example.rs
10. Verify with just runtool: rustdoc --edition=2021 -L . --test subdir/example.rs --runtool=tool/echo -Z unstable-options --nocapture
11. Try with both runtool and test-run-directory: rustdoc --edition=2021 -L . --test subdir/example.rs --runtool=tool/echo --test-run-directory=subdir -Z unstable-options --nocapture

I expected this to happen: The last step should always work.

Instead, this happened: The last step works on Windows, but fails on Unix-like platforms.

I general, Command::current_dir can be problematic with relative paths. One approach I recommend (and the one Cargo uses) is to check if the executable has a / or \, and if it does, do current_working_directory.join(exe_path) as the argument to Command::new.

Meta

rustc --version --verbose:

rustc 1.71.0-nightly (9d871b061 2023-05-21)
binary: rustc
commit-hash: 9d871b0617a4b3d6610b7cee0ab5310dcb542c62
commit-date: 2023-05-21
host: aarch64-apple-darwin
release: 1.71.0-nightly
LLVM version: 16.0.4

cc #56925
cc #64245