upstream to rustc about miri HOT 12 CLOSED

I just learned from this blog post that the Linux kernel repo has four initial commits. It doesn't seem like a big deal. One of their roots was even added by accident.

from miri.

There is an integration plan from last week's compiler design sprint here.

from miri.

interp

interpret, surely.

from miri.

An open question is how to integrate miri's source into rustc:

• go the rls way: integrate the miri repository as a submodule of the rustc repository
• go the clippy way: move the miri library into the rustc repository and only develop the miri executable in this repository.

@solson: have you done any work towards moving miri into rustc, or are planning on doing so any time soon? If not, do you mind if I give it a try?

from miri.

I haven't done any merging work yet, but I plan to do it relatively soon.

My basic idea was to create a mir_interp or mir::interp module somewhere (wherever @eddyb suggests) and get the code compiling there. I don't think we should use a submodule, so I agree with only developing the executable in this repo. It could depend on the rustc code, but that would limit experimentation in this repo (e.g. doing FFI calls) so maybe it should just exist separately. Unfortunately that requires manual syncing of the code...

We'll have to get rid of our dependency on the byteorder crate before merging into rustc.

from miri.

that would limit experimentation in this repo

I have an abstraction layer in mind, so the bulk of the code stays in the compiler and here you keep a driver and extensions to it.

from miri.

We'll have to get rid of our dependency on the byteorder crate before merging into rustc.

If you wait a few more days, the old makefiles are getting removed and you can just depend on crates.io.

from miri.

If I may recommend, git subtree is nice for preserving history with this sort of thing.

from miri.

git subtree showed up on IRC before, I believe my suggestion was to have a merge commit between two repos (connected by a git remote).

Now there's a way to actually make the commits valid in this repo: make a commit to move the files in the right position and roughly the right content, on a miri branch, then merge that branch into Rust.

from miri.

@brson @alexcrichton Would there be serious issues if we ended up with two roots (commits with no parents) in rust-lang/rust, in order to preserve miri's history? We can do something else otherwise.

from miri.

I don't really understand what the implications of such a situation would be, but I can't think of any reason offhand why that'd be bad

from miri.

Closing this, since Miri was in fact merged into rustc back in December in rust-lang/rust#45002, and later fully replaced the old const evaluator in rust-lang/rust#46882 just a couple weeks ago. (Thanks @oli-obk and everyone else involved!)

from miri.