-
Notifications
You must be signed in to change notification settings - Fork 371
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
Add Cargo.lock #427
Comments
I am going to close this, as it's not a big deal and I am not even sure if it is worth fixing. (There's also something good about always using the latest version, and with Miri being distributed via rustup soon, this does not affect users.) |
Reopening: in #992, CI failed because a bump in a crate, together with not having a lockfile, means Miri doesn't build on CI any more (the new version of compiletest-rs does not work with old nightlies any more). And until rust-lang/rust#65342 lands we also will be unable to make it build again, so Miri development is just halting until that situation is resolved. That's quite awful, and having a lockfile would avoid this kind of situation. @ehuss is there any way to have a lockfile here in the Miri repo in a way that when the same file appears in the rustc tree (due to it being a submodule), it does not cause trouble for cargo? |
I think it should be fine to add a You'll probably need to keep it somewhat in sync with rustc's lock file, which might be a little tedious, but probably better than not working at all. |
Hm, @oli-obk do you remember what the issue was? |
FWIW both RLS and Rustfmt have Cargo.lock in their repo and it doesn't cause issues for Rust. |
It would be nice to make use of locking, to make sure CI and me actually test the same stuff.
The problem, if I recall correct what @oli-obk said, is that this lockfile would be picked up by rustc as well through the submodule, and we do not want that. Is that right? How do other tools handle this?
The text was updated successfully, but these errors were encountered: