Difficult/confusing to use -Zbuild-std with cargo-multivers

[saethlin]

It's very tempting to use this with -Zbuild-std, because the standard library contains some algorithms which can be very amenable to instruction selection that depends on features above the baseline.

If I try to run

cargo +nightly multivers -- -Zbuild-std

I don't see any sign of the standard library being rebuilt. Maybe I'm missing it, but that looks like a bug somewhere. Maybe those arguments are dropped? Are they supposed to be passed through to Cargo?

If I try instead:

CARGO_UNSTABLE_BUILD_STD=std cargo +nightly multivers

The build crashes at the last phase with a bunch of errors like this:

error[E0152]: duplicate lang item in crate `core`: `sized`.
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /tmp/scratch/target/cargo-multivers/x86_64-unknown-linux-gnu/release/deps/libcore-c40ee5b690d29378.rlib, /tmp/scratch/target/cargo-multivers/x86_64-unknown-linux-gnu/release/deps/libcore-c40ee5b690d29378.rmeta
  = note: second definition in `core` loaded from /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-632ae0f28c5e55ff.rlib

This happens when building with -Cpanic=abort but when there's no panic_abort crate in the sysroot. It's rather surprising that I was quietly opted into aborting panics; but if a user knows about this situation it's not hard to pass

CARGO_UNSTABLE_BUILD_STD=std,panic_abort cargo +nightly multivers

... but if they don't, this just looks like a bug in cargo-multivers.

[Shnatsel]

cargo +nightly multivers -- -Zbuild-std used to fail with the same error in 0.6 but seems to have stopped correctly propagating the command-line arguments in 0.7

[ronnychevalier]

Maybe those arguments are dropped? Are they supposed to be passed through to Cargo?

Yes, the arguments you pass after -- are forwarded to each call to cargo build.

This happens when building with -Cpanic=abort but when there's no panic_abort crate in the sysroot. It's rather surprising that I was quietly opted into aborting panics.

Which version of cargo multivers are you using?

I just tested this with 0.7 and it works as expected:

• If you have a crate with a release profile that does not define panic=abort and call cargo +nightly multivers -- -Zbuild-std: it works.
• If you have a crate with a release profile that defines panic=abort and call cargo +nightly multivers -- -Zbuild-std: it does not work. This is expected, you should specify -Zbuild-std=std,panic_abort.
• If you have a crate with a release profile that defines panic=abort and call cargo +nightly multivers -- -Zbuild-std=std,panic_abort: it works.

With previous versions, like @Shnatsel said, a bug was present where all arguments after -- were also forwarded to the final cargo build. This final build is related to the runner (the one that performs runtime checks for the feature, patches, and uncompresses the right binary) that have a profile with panic=abort.

[saethlin]

Ah! The tripping hazard here is definitely just with the runner build, that's why it manages to do all the other compiles. I should have noticed that.

[ronnychevalier]

So does it work for you with version 0.7 or do you still have an issue?

[saethlin]

I don't have an issue. I opened this because @Shnatsel wasn't immediately aware what to do with the duplicate lang items diagnostic. I wanted to make sure that the current behavior is intentional; since it is it would be nice to have a short explanation in the README about the behavior with -Zbuild-std. I searched for mention of the flag right away and would have just referred to that if it existed.

[ronnychevalier]

You should not have duplicate lang item errors anymore. If you do it means your crate is defining panic=abort (or you are adding -Cpanic=abort), and you are only using -Zbuild-std without the panic_abort option.

I'm not sure what you think I should explain in the README?
I can add general recommendations about using -Zbuild-std (since you are right it is a good idea to use it, but one needs to be aware of the increased compile time) and how to use it properly?
Or do you mean adding an explanation that anything after -- is passed to each cargo build except the runner? (so you cannot rebuild the std of the runner if you want to)

[saethlin]

How about I answer that by sending a PR. I should have some time in the next week or two.

[Shnatsel]

cargo +nightly multivers -- -Zbuild-std does work in v0.7.

CARGO_UNSTABLE_BUILD_STD=std cargo +nightly multivers does not, but it's not immediately clear to me whether fixing that justifies the additional complexity required.

[ronnychevalier]

Oh ok I understand now, thanks. I was focused on -Zbuild-std and it was working, but I forgot that you mentioned CARGO_UNSTABLE_BUILD_STD and this one does get propagated to the cargo build of the runner...

The fix is straightforward, just one line to not propagate this environment variable.
But I guess by additional complexity, you mean the fact to not propagate all other potential environments variables that could affect the build of the runner, not just this one?

[ronnychevalier]

I pushed de28109, that fixes this specific behavior.
I think we should probably clear more than just this one variable, but in the mean time it should avoid the confusion if one uses the environment variable to rebuild the std.

[ronnychevalier]

0.8.0 has been released. It contains the fix mentioned above.

[saethlin]

I think you took care of everything I would have in my theoretical PR. Thank you!

[ronnychevalier]

Ok, closing then.