-
Notifications
You must be signed in to change notification settings - Fork 14k
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 foocd foomkdir tool- Create a runtool:
cat <<'EOF' > tool/echo.rs fn main() { eprintln!("{:?}", std::env::args().collect::<Vec<_>>()); } EOF rustc --out-dir tool tool/echo.rsmkdir 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