@Alex Crichton as expected, the std-can-depend-on-crates.io thing broke xargo building libstd. namely, I get
error[E0463]: can't find crate for `std` error: aborting due to previous error For more information about this error, try `rustc --explain E0463`. error: Could not compile `rustc-std-workspace-core`. warning: build failed, waiting for other jobs to finish... error: build failed error: `"cargo" "build" "--release" "--manifest-path" "/tmp/xargo.drywiPoxElbZ/Cargo.toml" "--target" "x86_64-unknown-linux-gnu" "-p" "std"` failed with exit code: Some(101)
any idea why something would look for
std when building
(Cc @Oli it might be a while until miri works again... also because I don't have much time to look after this, I really should be writing my master thesis^^)
wait wat? I thought you were doing a PhD?
on-topic: I'll try to figure something out. Maybe I'll just give
always-encode-mir another try by looking how large the impact of it is
yeah but I skipped the master and now I want to get it because reasons^^
hm it actually seems like it builds
rustc-std-workspace-core before it is even done building core...
that can't be though, there is an explicit dependency
but the build log is pretty clear...
Running `rustc --crate-name rustc_std_workspace_core /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-std-workspace-core-1.0.0/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C metadata=bf253d2d0bd6a6fb -C extra-filename=-bf253d2d0bd6a6fb --out-dir /tmp/xargo.7d0OnZnXb4ER/target/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/tmp/xargo.7d0OnZnXb4ER/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/xargo.7d0OnZnXb4ER/target/release/deps --cap-lints allow --sysroot /home/r/.xargo/HOST -Z force-unstable-if-unmarked` Running `rustc --crate-name build_helper /home/r/.rustup/toolchains/7489ee9c6f92050a12a3a3097df0a7d3737d82ec/lib/rustlib/src/rust/src/build_helper/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C metadata=63a15ced80c8c105 -C extra-filename=-63a15ced80c8c105 --out-dir /tmp/xargo.7d0OnZnXb4ER/target/release/deps -L dependency=/tmp/xargo.7d0OnZnXb4ER/target/release/deps` Running `rustc --crate-name core /home/r/.rustup/toolchains/7489ee9c6f92050a12a3a3097df0a7d3737d82ec/lib/rustlib/src/rust/src/libcore/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C metadata=528d977cf525b6bd -C extra-filename=-528d977cf525b6bd --out-dir /tmp/xargo.7d0OnZnXb4ER/target/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/tmp/xargo.7d0OnZnXb4ER/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/xargo.7d0OnZnXb4ER/target/release/deps --sysroot /home/r/.xargo/HOST -Z force-unstable-if-unmarked`
oh wait it actually uses the
rustc_std_workspace_core from GH, not the one it should be using
@RalfJ if xargo creates a fresh
Cargo.toml (which it looks like it does?) then it'll need a
[patch] to point to
the bug there is, yeah, using the crates.io version instead of the local version
yeah that's probably the problem
which is required to do so via
I didn't know that xargo copied the manifest :(
makes sense in retrospect...
@Alex Crichton got the patch line somewhere to copy-paste?
(pointer to some rust src file or so)
(I figured rustc needs to also do this somewhere)
only the last one is needed there (but
[patch.crates-io] is needed)
@Alex Crichton @Oli turns out that's enough :) https://github.com/japaric/xargo/pull/228
Not quite unfortunately :(