Broken sysroot when custom "release" profile sets panic="abort"

[RossSmyth]

Hello,

When attempting to use miri today I did the normal cargo +nightly miri test. But it failed to build the project with a mysterious error:

error: the crate panic_unwind does not have the panic strategy unwind

Eventually it was tracked down to me having a custom "release" profile, because I basically only use that profile for installing via cargo install. The key at fault is the panic = "abort" key.

This is quite easy to replicate. Set the envar CARGO_PROFILE_RELEASE_PANIC="abort" then try to run anything with miri. For example I build the miri test suite and every test failed with the error above. Then since the sysroot cache is polluted you have to delete it to fix it hence my open PR :).

cc @Nemo157

Nemo described it as "I'm not even seeing panic=abort in the rustc commands"

[saethlin]

This is quite easy to replicate. Set the envar CARGO_PROFILE_RELEASE_PANIC="abort" then try to run anything with miri. For example I build the miri test suite and every test failed with the error above. Then since the sysroot cache is polluted you have to delete it to fix it

I think the problem here is that CARGO_PROFILE_RELEASE_PANIC doesn't get included in the sysroot hash:
https://github.com/RalfJung/rustc-build-sysroot/blob/86794ef81ef7643630fcaa1c4b6156326cedb790/src/lib.rs#L250-L255

        src_dir.hash(&mut hasher);
        hash_recursive(src_dir, &mut hasher)?;
        self.config.hash(&mut hasher);
        self.mode.hash(&mut hasher);
        self.rustflags.hash(&mut hasher);
        rustc_version.hash(&mut hasher);

I'm not surprised that we're missing a number of things in the hash. Maybe the right way to go is to include every env var that starts with CARGO_?

[RalfJung]

No I don't think this is a hashing issue. Building the sysroot with panic="abort" just doesn't make sense. We shouldn't apply custom "release" profiles in the sysroot build.

[Nemo157]

Nemo described it as "I'm not even seeing panic=abort in the rustc commands"

This was when trying to go full into panic=abort mode with:

CARGO_PROFILE_RELEASE_PANIC=abort CARGO_PROFILE_DEBUG_PANIC=abort cargo miri test -Zpanic-abort-tests

[RossSmyth]

Well to be specific, this happened without setting the env var. I don't know if cargo sets it for me, but I just have a profile in .cargo/config.toml

[Nemo157]

The env-var is just an alternative way to set cargo's config, if you use cargo config get it will read both env-vars and config files for you.

[RossSmyth]

Sort of related to rust-lang/cargo#7621 since isolating from external configs would fix this.

[RalfJung]

Could we "isolate" by just setting a profile that people are unlikely to have configured (and if they configure a "miri_sysroot" profile and things break, it's really on them)?