Repository navigation
--emit KIND=PATH cannot handle paths containing commas #159743
Description
I tried this code:
#!/usr/bin/env bash
set -eu
rustc=$(rustup which rustc)
rustdoc=$(rustup which rustdoc)
tmp=$(mktemp -d); trap 'rm -rf "$tmp"' EXIT
out="$tmp/with,comma"; mkdir "$out"
echo '' > "$tmp/lib.rs"
check() { # $1=label; rest=command
echo "### $1"; shift
"$@" 2>&1 | sed 's/^/ /'
echo
}
"$rustc" --version; echo
check "rustc" \
"$rustc" --crate-name t --crate-type lib --out-dir "$out" \
--emit=dep-info="$out/t.d" "$tmp/lib.rs"
check "rustdoc" \
"$rustdoc" --crate-name t -o "$out" \
--emit=html-non-static-files,dep-info="$out/t.d" "$tmp/lib.rs"I expected to see this happen:
rustc 1.99.0-nightly (9f36de775 2026-07-19)
### rustc
### rustdoc
(all three invocations succeed and write dep-info file to the path under with,comma/)
Instead, this happened:
rustc 1.99.0-nightly (9f36de775 2026-07-19)
### rustc: single kind
error: unknown emission type: `comma/t.d` - expected one of: `asm`, `llvm-bc`, `dep-info`, `link`, `llvm-ir`, `metadata`, `mir`, `obj`, `thin-link-bitcode`
### rustdoc
error: unrecognized emission type: comma/t.d
Both rustc and rustdoc split the entire --emit value on commas before recognizing the KIND=PATH form,
so everything after a comma inside PATH is misparsed as another emission type.
There is no escape mechanism btw.
Isolating a single KIND=PATH in its own --emit also doesn't help.
Meta
rustc --version --verbose:
rustc 1.99.0-nightly (9f36de775 2026-07-19)
binary: rustc
commit-hash: 9f36de775bc636c8e88c31a173c2bcb6995956a0
commit-date: 2026-07-19
host: aarch64-apple-darwin
release: 1.99.0-nightly
LLVM version: 22.1.8
How this was discovered
While stabilizing -Zrustdoc-depinfo,
Cargo started passing --emit=html-static-files,html-non-static-files,dep-info=<path> to rustdoc,
where <path> is an absolute path under the target directory.
If there is a comma in the target-dir path,
cargo doc would fail with unrecognized emission type.
Thanks @0xPoe for catching that in rust-lang/cargo#17020 (comment)!
Activity
ChrisDenton commentedon Jul 22, 2026
Hm, I think this would be hard to support without breaking? It currently supports doing something like:
Where the
,is not intended to be part of the path. We could maybe allow"around paths (they'd need to be escaped in the shell) but then you wouldn't be able to have quotes in paths (maybe that's a fair trade off?). EDIT: wait unless it also supports escapes, which is fun.An escape hatch would probably require a new argument that only allows a single
KEY=VALUEpair each time it's used.weihanglo commentedon Jul 22, 2026
Yeah, it is a bit tricky. I cannot think of a better solution than a new option you proposed.
Also, I was surprised there is no existing issue about it. Maybe because no one uses this feature except build systems, and build systems using it usually have a opinionated path layout.