Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upstream to rustc #105

Closed
oli-obk opened this issue Jan 25, 2017 · 12 comments
Closed

upstream to rustc #105

oli-obk opened this issue Jan 25, 2017 · 12 comments

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Jan 25, 2017

Leaving things to do here so they don't get lost

@eddyb in IRC:

replace the LLVM-generating stuff in trans with lowering miri allocations to LLVM
it should be more efficient in cases without relocations because you can give LLVM a byte blob
not sure if its own load-from-constant folding can deal with it

@oli-obk
Copy link
Contributor Author

oli-obk commented Jan 27, 2017

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?

@solson
Copy link
Member

solson commented Jan 28, 2017

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.

@eddyb
Copy link
Member

eddyb commented Jan 28, 2017

interp

interpret, surely.

@eddyb
Copy link
Member

eddyb commented Jan 28, 2017

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.

@eddyb
Copy link
Member

eddyb commented Jan 28, 2017

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.

@Ericson2314
Copy link

Ericson2314 commented Jan 29, 2017

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

@eddyb
Copy link
Member

eddyb commented Jan 29, 2017

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.

@solson
Copy link
Member

solson commented Feb 13, 2017

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

@eddyb
Copy link
Member

eddyb commented Feb 13, 2017

@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.

@alexcrichton
Copy link
Member

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

@solson
Copy link
Member

solson commented Feb 15, 2017

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.

@solson
Copy link
Member

solson commented Mar 20, 2018

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!)

@solson solson closed this as completed Mar 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants