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: Details |
|
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
|
|
||
| // 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.
Should this be a hard error?
There was a problem hiding this comment.
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.
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.
Then the lock file exists in the same place.
There was a problem hiding this comment.
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.
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.