rustdoc --runtool
uses ambiguous relative paths with --test-run-directory
#112210
Labels
A-doctests
Area: Documentation tests, run by rustdoc
C-bug
Category: This is a bug.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
The current code for
--runtool
can interact in platform-specific ways with--test-run-directory
because it usescurrent_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
rustc --out-dir tool tool/echo.rs
mkdir subdir
rustc --crate-type=rlib subdir/example.rs
rustdoc --edition=2021 -L . --test subdir/example.rs
rustdoc --edition=2021 -L . --test subdir/example.rs --runtool=tool/echo -Z unstable-options --nocapture
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, docurrent_working_directory.join(exe_path)
as the argument toCommand::new
.Meta
rustc --version --verbose
:cc #56925
cc #64245
The text was updated successfully, but these errors were encountered: