Library builds fail when path contains a percent char (%) #79567
Description
I have read CONTRIBUTING.md as well as the contributing guidelines. Searching for '%' and 'percent' does not seem to lead to any relevant existing issues. From my understanding of man cargo, man cargo-build and The Cargo Book, they do not make it obvious that restrictions like these should be imposed. Neither does man rustc seem to state that the %-character should be treated special in any way.
I tried this code:
mkdir -p '%/foo'
cd '%/foo'
cargo init --lib
cargo build Compiling foo v0.1.0 (/%/foo)
Running `rustc --crate-name foo --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=bed926cd50182e06 -C extra-filename=-bed926cd50182e06 --out-dir '/%/foo/target/debug/deps' -C 'incremental=/%/foo/target/debug/incremental' -L 'dependency=/%/foo/target/debug/deps'`
error: failed to build archive: No such file or directory
error: aborting due to previous error
error: could not compile `foo`.
Caused by:
process didn't exit successfully: `rustc --crate-name foo --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=bed926cd50182e06 -C extra-filename=-bed926cd50182e06 --out-dir '/%/foo/target/debug/deps' -C 'incremental=/%/foo/target/debug/incremental' -L 'dependency=/%/foo/target/debug/deps'` (exit code: 1)
%
I expected to see this happen: A successful build, comparable to if doing
mkdir -p '%/bar'
cd '%/bar'
cargo init --bin
cargo build --verbosecargo build
Compiling bar v0.1.0 (/%/bar)
Finished dev [unoptimized + debuginfo] target(s) in 0.65s
%
Instead, this happened: The build fails, whenever the actual directory or any parent contains at least one percent character. I can only speculate on why, but it would be likely to assume some tool upon which rustc depends treats percent characters as special, and that rustc is missing some escaping which should be performed.
For what its worth, this was found due to it causing real issues with our specific use of a fairly common continuous integration system. We can work around it, but it would be great if the need for such mitigation could be removed.
Meta
This applies to 1.47.0, 1.48.0 as well as 1.50.0-nightly (bfca1cd22 2020-11-24), on at least linux and illumos.
uname -srvmpio; rustc --version --verbose:
SunOS 5.11 omnios-r151030-58b4169e77 i86pc i386 i86pc illumos
rustc 1.48.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-illumos
release: 1.48.0
LLVM version: 11.0
uname -srvmpio; rustc +nightly --version --verbose:
Linux 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 unknown unknown GNU/Linux
cargo +nightly --verbose --version
cargo 1.50.0-nightly (bfca1cd22 2020-11-24)
release: 1.50.0
commit-hash: bfca1cd22bf514d5f2b6c1089b0ded0ba7dfaa6e
commit-date: 2020-11-24
Backtrace
N/A Build fails.