search

GaloisInc / mir-json

Plugin for rustc to dump MIR in JSON format
Apache License 2.0
9 stars 2 forks source link

Publish to crates.io #48

Open stefnotch opened 1 year ago

stefnotch commented 1 year ago

It'd be lovely if this tool were published to crates.io, like the majority of Rust tools.

Then the installation instructions might be simpler for users who already have Rust.

RyanGlScott commented 1 year ago

I agree. One reason that we haven't yet uploaded mir-json to crates.io is that any given mir-json release would only be buildable with a particular rustc nightly, and I could imagine lots of bug reports from confused users who try to install mir-json with an unsupported rustc version. That being said, we could include a rust-toolchain.toml file to ensure that when a user runs cargo install mir-json, cargo will download the correct nightly before attempting to build the tool.

RyanGlScott commented 1 year ago

Actually, I'm not sure if rust-toolchain.toml takes effect with cargo install or not. It would take effect if you cloned the mir-json repo and built it from source, which would simplify the current story slightly (in that you wouldn't need to manually change your Rust toolchain before building).

stefnotch commented 1 year ago

Ah, I see. I suppose a stable mir format would be needed for it to work with multiple rustc versions.

I personally would love anything that simplifies the installation instructions. Even getting rid of a single step is frequently worth it, in my opinion.

RyanGlScott commented 1 year ago

Ah, it turns out that we already have a rust-toolchain.toml file:

https://github.com/GaloisInc/mir-json/blob/3b538589852282a752e517b69fc61b627cd6d4bd/rust-toolchain.toml#L1-L2

I think that we need to add components = ["rustc-dev"] as well, but most of the ingredients are there.

Another thought that popped into my mind: there are several commands inside of mir-json that spawn rustc subprocesses. If a user installs mir-json with one rustc version (the intended version) but later changes their toolchain to have a different rustc version as the default, will mir-json's rustc subprocesses still pick the intended version? Surprisingly, some experimentation suggests that the answer is "yes". I'm not sure how that works exactly, but that is a fortunate coincidence.

spernsteiner commented 1 year ago

If a user installs mir-json with one rustc version (the intended version) but later changes their toolchain to have a different rustc version as the default, will mir-json's rustc subprocesses still pick the intended version? Surprisingly, some experimentation suggests that the answer is "yes".

I suspect this only works in certain cases. The various mir-json binaries link against a specific version of the rustc libraries and will always behave like the nightly they're built against. But we might run into trouble when invoking normal rustc instead of mir-json or one of our other binaries. In particular, using cargo crux-test in a project that uses proc macros might compile the proc macros with the default toolchain and produce proc macro crates that can't be loaded by mir-json.

We could probably fix this by setting RUSTUP_TOOLCHAIN or passing +nightly-xxx args in more places.

RyanGlScott commented 1 year ago

But we might run into trouble when invoking normal rustc instead of mir-json or one of our other binaries.

To be clear, this is the scenario I was referring to in my comment in https://github.com/GaloisInc/mir-json/issues/48#issuecomment-1660891752. Somehow, every rustc invocation that mir-json uses managed to pick the right rustc version when I tried it, even when a different rustc was selected as the default toolchain. This might have simply been a lucky fluke, however. I agree that we should be using RUSTUP_TOOLCHAIN/+nightly-xxx to make this more foolproof.