cargo-script
cargo-script copied to clipboard
DanielKeep
Weird situation where cargo hangs.
For some reason cargo script --dep rand --dep rand_derive -e '1+2' will cause one of cargo-script's children to hang on my system (using process explorer I can see 0 cpu time is being used
I believe this could be a bug in cargo, rather than cargo-script, but a regular crate with those dependencies compiles just fine, and I'm not sure what cargo-script is doing differently to trigger this, as with RUST_LOG=trace it looks like the hanging subcommand is called in cargo_target_by_message, but manually running the same command that shows up in the trace output completes fine.
ETA: Gnu toolchain cargo 0.23.0-nightly (e447ac7e9 2017-09-27) rustc 1.22.0-nightly (8493813cd 2017-10-22) cargo-script 0.2.7 Windows 10 v1607
I can confirm I'm seeing this behaviour too, but on Windows only.
Running the command which hangs (cargo build --manifest-path ... --release --message-format=json) manually in a separate terminal completes successfully, so I'm more inclined to think that there's an issue with std::process rather than cargo itself.
MSVC toolchain cargo 0.22.0 (3423351a5 2017-10-06) rustc 1.21.0 (3b72af97e 2017-10-09) cargo-script 0.2.7 and 0.2.6 Windows 10 v1709
*groans*
Alright, so if this is an issue with std itself, I'm loathe to start trying to hack around that. However, this code path is only used to work out what the path to the output executable is. Previous versions just used an heuristic to guess what the path would be. I changed it because people wanted to do weird things (like run executables cross-compiled to a different target for some insane reason), and this was "more correct".
"More correct" doesn't help when it's also "really stupidly broken".
Since this only appears to be a problem on Windows, what I will do is change it so that cargo-script goes back to the heuristic on Windows by default until such time that std is fixed (or a more immediately addressable culprit is found). Of course, Windows is also the only platform on which cross-compiling executables and then immediately running them even makes any damn sense, so I suppose I'll have to add an environment variable or something to turn the "correct" behaviour back on again.
Ok, 0.2.8 is up and reverts back to the old heuristic on Windows. I'm leaving this issue open until the work-around can be removed and the problem is fixed properly.
If the issue is that Command::status doesn't read from piped stdout/stderr, could you set them to null instead of piped?
