fix build.rs invoking RUSTC to do check builds #2436
Conversation
test-cargo-miri/build.rs
Outdated
| @@ -20,4 +20,9 @@ fn main() { | |||
| println!("cargo:rerun-if-changed=build.rs"); | |||
| println!("cargo:rerun-if-env-changed=MIRITESTVAR"); | |||
| println!("cargo:rustc-env=MIRITESTVAR=testval"); | |||
|
|
|||
| // Test that autocfg works. | |||
There was a problem hiding this comment.
Arguably this is testing cargo-miri build script support so having this in test-cargo-miri is the right place IMO.
|
Oh interesting, this fails in cross-mode. That is probably a problem even before the recent RUSTC changes, but would be nice to find a way to fix it... |
|
@rustbot author |
rustbot
added
the
S-waiting-on-author
|
Ah, the problem is that it uses the wrong sysroot. That's why we usually forward rustc invocations through cargo-miri -- it adjusts the sysroot. I had to completely redo the way we manage the sysroot for this, but now it should be working. |
RalfJung
changed the title
this requires a change in sysroot handling: miri driver now requires MIRI_SYSROOT to be set when it is in 'target' mode, rather than relying on `--sysroot` always being present.
|
Okay this is now quite different from where it started, and also works much better. I have updated the PR title and description accordingly. @rustbot ready |
rustbot
added
S-waiting-on-review
|
Oooh you figured out the env var dance with unsetting for recursive cases. I gave up on that. I should make a graph of what invokes what some day... |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
This makes the Miri driver, when invokved via the RUSTC env var from inside a build script, behave almost entirely like rustc. I had to redo how we propagate sysroot information for this (which is actually back to how we used to do sysroot propagation many years ago).
Fixes #2431