Use 'cargo check' to build the sysroot and target crate #1136
Conversation
b07f3ac to
29b2fad
Compare
src/bin/cargo-miri.rs
Outdated
| @@ -197,7 +227,7 @@ fn xargo() -> Command { | |||
| // Bootstrap tells us where to find xargo | |||
| Command::new(val) | |||
| } else { | |||
| Command::new("xargo") | |||
| Command::new("xargo-check") | |||
There was a problem hiding this comment.
It really is that easy 😄
There was a problem hiding this comment.
Well, longer-term we'd ideally also stop creating a Cargo.toml. ;)
|
I remain pretty skeptical of the enormous hacks this introduces, and would prefer something relying on |
df667ff to
d980c36
Compare
|
@RalfJung: I've modified this PR to distinguish between crate types using only the command-line arguments passed by Cargo. Using the target directory turned out to be unnecessary - |
|
What about |
|
@RalfJung: We need to check for I think using I think checking for the presence of one flag |
|
Looks like I'll need to look closer into this and do some experiments myself to fully appreciate what is happening here. That might take a few weeks until I find the time, sorry. |
d980c36 to
7bcf51a
Compare
I don't think we need to look at the root directory at all, we can just call But you are right that this is not really much less hacky than your variant, if at all. So since this works, we can just use it. I did some slight refactoring like moving the test methods down inside @bors r+ |
|
📌 Commit 7bcf51a has been approved by |
This comment has been minimized.
This comment has been minimized.
Fixes rust-lang#1057 Since we are no longer using "cargo rustc", we now use the rustc arguments passed by Cargo to determine whether we are building a build dependency, normal dependency, or "target" (final binary or test) crate.
7bcf51a to
443163f
Compare
|
@bors r+ |
|
📌 Commit 47f2b12 has been approved by |
Use 'cargo check' to build the sysroot and target crate Fixes #1057 I'm using my original approach from PR #1048. Ideally, we would distinguish between build-deps/dependencies/'final crate' via a different approach (e.g. the target directory). However, I haven't been able to get that to work just yet. However, everything should be working with the approach I'm using. At a minimum, we can use this PR to verify that everything works as expected when we don't actually produce native build outputs.
|
💔 Test failed - status-appveyor |
|
@bors r+ |
|
📌 Commit faf7bf5 has been approved by |
|
☀️ Test successful - checks-travis, status-appveyor |
…c-morse no more codegen for miri_start_panic With rust-lang/miri#1136 landed, we don't generate code any more for crates that will be run by Miri. So the LLVM backend does not have to implement the `miri_start_panic` intrinsic any more. Cc @Aaron1011
| } | ||
|
|
||
| fn cargo() -> Command { | ||
| if let Ok(val) = std::env::var("CARGO") { |
There was a problem hiding this comment.
I would like to use env;:var_os when ever it is possible.
There was a problem hiding this comment.
That probably makes sense, if we don't need it to really be UTF-8... do you want to submit a PR?
Fixes #1057
I'm using my original approach from PR #1048. Ideally, we would
distinguish between build-deps/dependencies/'final crate' via a
different approach (e.g. the target directory). However, I
haven't been able to get that to work just yet.
However, everything should be working with the approach I'm using. At a
minimum, we can use this PR to verify that everything works as expected
when we don't actually produce native build outputs.