Open nospam3089 opened 3 years ago
FWIW this works for me on linux, so I'd expect this to be specific to SunOS.
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.
@jyn514 ^
Perhaps a different distro is the problem?
Can confirm this occurs on macOS too:
Created library package
Compiling foo v0.1.0 (/Users/user/%/foo)
error: failed to build archive: No such file or directory
error: aborting due to previous error
error: could not compile `foo`
Looks like it occurs in rustc_codegen_llvm:
Might be an LLVM bug.
@rustbot ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some instructions for tackling these sorts of bugs. Maybe take a look? Thanks! <3
cc @camelid @comex @cuviper @DutchGhost @hdhoang @heyrutvik @higuoxing @JOE1994 @jryans @mmilenko @nagisa @nikic @Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique
@camelid I think the reason is because llvm::writeArchive(..)
creates a temp file as follows:
Expected<sys::fs::TempFile> Temp =
sys::fs::TempFile::create(ArcName + ".temp-archive-%%%%%%%.a");
It ends up hitting this code path. The %
in the file path gets formatted with a random character. It looks like it's common in their tree to call sys::fs::TempFile::create(Prefix + ".temp-archive-%%%%%%%.a")
, and Prefix
is assumed not to contain any %
characters. Seems like something that should be fixed upstream. mktemp
has a similar API but only replaces the X
s in the final component. In the LLVM tree, the intended replacements seem to happen if the string of %
s are the final characters, or if they are between the final -
and the file extension.
I created a report upstream https://bugs.llvm.org/show_bug.cgi?id=49750
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 doesman rustc
seem to state that the%
-character should be treated special in any way.I tried this code:
I expected to see this happen: A successful build, comparable to if doing
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
:uname -srvmpio; rustc +nightly --version --verbose
:Backtrace
``` N/A Build fails. ```