Stream: general

Topic: cargo install miri

RalfJ (Nov 12 2018 at 19:42, on Zulip):

@Oli What do you think, can we make it so that cargo install miri will get people to run miri? I assume we'd have to (a) enable the cargo-miri feature per default, and (b) upload miri to, and (c) re-upload it every other day to fix things for latest nightly. I have no idea how much effort the last two parts are, in particular considering that we'd likely have to re-publish fairly frequently. Can several people have publishing rights for the same crate? Do you even think we should do this?

Jake Goulding (Nov 12 2018 at 20:08, on Zulip):


probably not the best place :-)

Can several people have publishing rights for the same crate


RalfJ (Nov 13 2018 at 07:29, on Zulip):

lol, yes,^^ @Oli what do you think?

oli (Nov 13 2018 at 08:15, on Zulip):

I think that we've had a lot of pain with this in clippy

oli (Nov 13 2018 at 08:16, on Zulip):

but I see no way around it other than adding a miri rustup component

RalfJ (Nov 13 2018 at 08:24, on Zulip):

pain of which kind?

oli (Nov 13 2018 at 08:34, on Zulip):

keeping the crate up to date takes a lot of effort. People have trouble figuring out which nightly needs which miri version

RalfJ (Nov 13 2018 at 09:12, on Zulip):

What is that effort? Can we not have a ./publish-new-version script?

oli (Nov 13 2018 at 09:17, on Zulip):

the effort on our end is mostly issues being opened about miri not working because of too new or too old nightlies and some nightlies having no valid miri version

oli (Nov 13 2018 at 09:18, on Zulip):

I can only speak from the clippy experience. Everything became much more chill once we were going the rustup path

RalfJ (Nov 13 2018 at 09:26, on Zulip):

Sure, but that's not currently realistic for miri I think.

RalfJ (Nov 13 2018 at 09:26, on Zulip):

The two alternatives are to keep doing what we do now, or to try using

Pietro Albini (Nov 13 2018 at 11:55, on Zulip):

well, it might be less painful to have miri as a rustup component right now, since we don't block nightlies on missing components

RalfJ (Nov 13 2018 at 11:59, on Zulip):

if the team (whichever team is relevant here^^) would be up for that, I'd be delighted. miri is still rather experimental and far from being remotely as polished as e.g. clippy, not sure if that factors into the equation.

gnzlbg (Nov 13 2018 at 11:59, on Zulip):

@RalfJ you might want to look into shipping miri as a component, e.g. rustup component add miri-preview

RalfJ (Nov 13 2018 at 12:00, on Zulip):

a component is also what clippy etc are, right?

RalfJ (Nov 13 2018 at 12:01, on Zulip):

Who makes decisions about adding components?

Pietro Albini (Nov 13 2018 at 12:12, on Zulip):

clippy-preview and llvm-tools-preview were approved by the dev tools team, IIRC

pnkfelix (Nov 27 2018 at 13:33, on Zulip):

@Oli is there a good place I can go to read about (i.e. learn more) the pain clippy had when it was on instead of being a rustup component?

pnkfelix (Nov 27 2018 at 13:34, on Zulip):

I ask because I've been privately musing about trying to refactor compiletest so that some/all of it is hosted on or something like that, or at least is in a separate repo from rust-lang/rust where we can do independent development.

oli (Nov 27 2018 at 13:35, on Zulip):

not really, all we have is the big list of issues people were opening when things didn't work because you needed to match nightly versions

centril (Nov 27 2018 at 13:35, on Zulip):

@pnkfelix there's a version of compiletest on that folks use to test proc macros macros and such

oli (Nov 27 2018 at 13:35, on Zulip):

some things have improved since then

oli (Nov 27 2018 at 13:36, on Zulip):

like clippy's CI using PR rustc instead of nightly rustc

oli (Nov 27 2018 at 13:38, on Zulip):

I wish we could have stable compiletest, but all my attempts have ended in chaos so far

oli (Nov 27 2018 at 13:39, on Zulip):

I basically decided to give up until custom test frameworks

pnkfelix (Nov 27 2018 at 13:40, on Zulip):

I wish we could have stable compiletest, but all my attempts have ended in chaos so far

sorry, what were your previous attempts? Could you add more detail here, so that I don't go down similar paths in quiet isolation?

oli (Nov 27 2018 at 13:56, on Zulip):

My initial naive approach was to rip out whatever libtest and compiletest both need into a stable crate and then get rid of the libtest dependency of compiletest. That doesn't really work, because then you end up with allmost all of libtest in the "stable" crate, which in itself isn't possible because of all the feature gates.

oli (Nov 27 2018 at 13:57, on Zulip):

I managed to get a few commits into compiletest that removed a bunch of unnecessary feature gates, but it still shares a large core with libtest

oli (Nov 27 2018 at 13:58, on Zulip):

I have never been able to figure out why we need all that, so my next idea was to start removing features from compiletest that depended on libtest. I don't think I ever managed to get something worthwile done that didn't end up affecting all of compiletest and consequently breaking it

Last update: Aug 13 2020 at 09:00UTC