Description
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:
mkdir foo
cd foo
mkdir tool
- Create a runtool:
cat <<'EOF' > tool/echo.rs fn main() { eprintln!("{:?}", std::env::args().collect::<Vec<_>>()); } EOF
rustc --out-dir tool tool/echo.rs
mkdir subdir
- Create a test file:
cat <<'EOF' > subdir/example.rs /// ``` /// example::foo(); /// ``` pub fn foo() {} EOF
rustc --crate-type=rlib subdir/example.rs
- Verify test works:
rustdoc --edition=2021 -L . --test subdir/example.rs
- Verify with just runtool:
rustdoc --edition=2021 -L . --test subdir/example.rs --runtool=tool/echo -Z unstable-options --nocapture
- 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