@Oli @Andrew Poelstra I am wondering if we can remove the footgun of forgetting to pass
-- -Zmiri-start-fn to
cargo miri, which leads to memory leaks errors because TLS wasn't initialized (and maybe there are other errors?). I see several options, but I am not sure which one I like most:
-Zmiri-start-fnand instead auto-detect if we have a libstd with all the MIR (looking up some monomorphic function and seeing if it got MIR). That would be most convenient and it matches the state we used to have before the
start_fnlang item got polymorphic.
cargo miri. Forces people to get a libstd with full MIR, even if their code doesn't otherwise need it.
-Zmiri-start-fnis passed. Seems like a shame though, we have an entire test suite showing that the leak check works just fine there.
My tendency is with the first option, I have to say. Fewer flags always seem nice^^
first option sounds good. I nominate
rust_panic as the canary
that was fast :P
On a related note... @Andrew Poelstra so what do we do about https://github.com/solson/miri/pull/483 ? Do you still think we should tell the user to copy stuff around? I think we shouldn't. We should rather tell them to do
cargo clean, and then
MIRI_SYSROOT=~/.xargo/HOST cargo miri, and that should work without any copy.
@Christian Poveda welcome to Zulip :D
@Oli your two suggestions would become separate commits, so I am going to make them one commit manually instead
yea, the feature is cool, but not quite ready yet
lol when you work on rustc+miri and const validation tells you your miri sources contain a bad const^^
@RalfJ agreed, I should change the PR to recommend
cargo clean rather than copying stuff around. That's much simpler
@Andrew Poelstra also with
-Zmiri-start-fn gone thinks are hopefully a bit better now
I think the biggest footgun left is not using the same toolchain for
cargo miri. Should probably be mentioned: "If you get strange errors, try
cargo clean and make sure you used the same toolchain for ..."
I actually don't know what
-Zmiri-start-fn does. I haven't able to build something without a MIR-enabled std to run
cargo miri on it
Agreed -- even now sometimes I forget to set MIRI_SYSROOT and things break with "cannot find std". Now I know the correct response is
cargo clean and then set MIRI_SYSROOT, but at first this was extremely confusing
so I'll update the README PR to say that