-
Notifications
You must be signed in to change notification settings - Fork 93
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
Use the lockfile shipped with rust-src #255
Conversation
This reverts commit a4853d5. compiler-builtins is nowadays pulled in via crates.io, so let's give locking another shot.
Hm @jethrogb this makes your |
Unfortunately the test framework doesn't show the test output, only that it didn't contain certain substrings... Are we passing |
The build log looks like this:
|
In particular it says
The lockfile references v1.0.35 of that crate, which likely is why the patch does not apply. |
Seems like that worked! CI is green. |
@jethrogb what do you think? Should we try to use the lockfile shipped with rust-src? |
Not if we have to keep changing the test so we match the version with whatever |
I think the benefits far outweigh this cost. Right now, a new release of any of the crates libstd depends on can break the build any time. This has happened recently (when a new rustc-std-workspace-std was released), and it has happened before last year. Maybe we should run that test only on a pinned version of nightly. But I think being able to reliably and reproducibly build old versions of libstd is important, more important than having this particular test work with zero maintenance. |
bors try Let's see which version the pinned 2018-12-01 nightly needs, then we can just pin the test to that. |
tryBuild failed |
bors try |
tryBuild succeeded |
That seems to have worked. With this, the patch test should not fail as nightly Rust changes. |
Ok but you're using the same cc version for every pinned nightly, this will break if we ever add another one. |
Can we parse the needed cc version from Cargo.lock? |
It will. I can update the test then (make it depend on which nightly is pinned).
We probably can. I am just not convinced that's worth the effort. But if you insist, I can work on that. Not sure when I will have the time, though. |
src/sysroot.rs
Outdated
@@ -98,6 +99,10 @@ version = "0.0.0" | |||
stoml.push_str(&profile.to_string()) | |||
} | |||
|
|||
// rust-src comes with a lockfile for libstd. Use it. | |||
let lockfile = src.path().join("..").join("Cargo.lock"); | |||
fs::copy(lockfile, &td.join("Cargo.lock")).chain_err(|| "couldn't copy lock file")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a hard error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? All versions of rust-src that we support have this file. It is present since 2017.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you're getting your source not from the rust-src
package? Like git? Or a local git clone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then the lock file exists in the same place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure but the user may have deleted it. I'm ok with forcing that it exists, but the error message should be slightly clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair. I made it "Cargo.lock file is missing from source dir".
r=me after minor change |
bors r=jethrogb |
Build succeeded |
262: version bump for 0.3.17 release r=jethrogb a=RalfJung Right now Miri is broken on macOS and Windows because an updated compiler_builtins has problems, and we don't use the lockfile that would make us use the old version. So, it's time to release a xargo with #255. Co-authored-by: Ralf Jung <post@ralfj.de>
This reverts a prior revert.
compiler-builtins is nowadays pulled in via crates.io, so let's give locking another shot.