-
Notifications
You must be signed in to change notification settings - Fork 13.3k
sync Miri #102464
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
sync Miri #102464
Conversation
The Miri subtree was changed cc @rust-lang/miri |
@bors r+ p=1 tool sync |
📌 Commit bae2388116acb768e1de6f5d76fae696c97fe811 has been approved by It is now in the queue for this repository. |
@bors r=oli-obk Do we still need p=1? Miri isn't broken, after all. |
📌 Commit d541412026b3245b7f94deb9eb1325ef5cd7518c has been approved by It is now in the queue for this repository. |
Of course the next josh sync from rustc to Miri will duplicate this commit there... |
may be less annoying to resolve conflicts. Not sure what the policy on clippy syncs is |
@bors r-
Investigating CI failures
|
Argh, people changed their licenses...
|
Maybe we should just get rid of vergen, that would help with some of these. clippy seems to use a local copy of https://crates.io/crates/rustc_tools_util. @oli-obk is it okay to use the crates.io version of that crate? |
@RalfJung the original source of the crate lives in the clippy repo, it shouldn't be a fork :D |
Yeah I realized it's not a fork, but if Miri now uses the crates.io version then we have code duplication in the rustc workspace. Also the crates.io version is outdated but I don't know if the diff is relevant. |
The unicode-ident error is strange -- this is a cargo-miri dependency, but we get an error for it supposedly being a rustc dependency? |
Ah, this updates proc-macro2 which switched from unicode-xid to unicode-ident. However if we avoid vergen I think we can also avoid updating syn and then this license becomes someone else's problem...^^ |
... and this does seem to lead to conflicts down the road, when I try to sync rustc back into Miri after this PR. I am not quite sure how to proceed here. This might be fine for a one-off change, but longer term we probably want to get josh to work for both directions, which I guess would work better if we had done the initial subtree merge with josh instead of git-subtree... but now we need to figure out how to live with the repo that we have. |
Well... the proper josh way would be to erase all miri history here, us not doing that is where the failure to sync miri->rustc is coming from. Alternatively... we can re-sync the src/tools/miri folder from scratch... creating another duplication of all miri commits in the rustc repo 🙈 |
How can we erase history in git?
Is it literally the original commits? Because then it wouldn't duplicate, it would reference the same commits that git-subtree already added to the repo. |
hmm... I don't believe it works the same way, no. josh rewrites the commits afaict. |
(after looking a bit more into josh) Yeah, josh would rewrite the Miri commits to happen below |
Okay so I think the reason syncing usually just 'magically' works in josh is that when we sync Miri changes into rustc, and then export them to Miri again again, they end up with the original SHA. So then syncing them into Miri again should work neatly. Using josh only for one direction will not work well I think. |
I got josh to create a sync, pushed to alternative PR #102573. |
Created via
r? @oli-obk