-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Bootstrap from 1.28.0 beta #51717
Bootstrap from 1.28.0 beta #51717
Conversation
r? @bluss (rust_highfive has picked a reviewer for you, use r? to override) |
Isn't this actually using 1.28.0-beta.1? |
Ah, yes, it is. |
Why not increase the |
@kennytm Fixed |
Assuming it's not waiting for other things... @bors r+ |
📌 Commit 21ac42514969a0d404f0b6ccd3c6be40c40dee02 has been approved by |
⌛ Testing commit 21ac42514969a0d404f0b6ccd3c6be40c40dee02 with merge 41a0eb34ce2f8be23c0ba27b54587a45c22caefc... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@bors r=kennytm |
📌 Commit 1bccafdb3c8b6e97c862dee449023b9b59f2397a has been approved by |
|
⌛ Testing commit 1bccafdb3c8b6e97c862dee449023b9b59f2397a with merge 5032ff2d8054fd30537fb4ac46cda4aa7471ba05... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I've tried to track this issue down but so far been fairly unsuccessful in determining the root cause. We're generating what appears to be two different version of libcore but I can't tell where the one in the sysroot is coming from -- no other file matches its hash in the build directory. This leads me to believe that either Cargo is overwriting files when generating the coretests -- this feels fairly likely considering that we see I'm not sure why core is being recompiled -- what we should see is just coretests being compiled. It is unclear to me why Cargo compiles core, though it loosely looks like it could be somewhat of a bug. The below fingerprint error is the only one I see related to libcore in this invocation of Cargo, yet we see that cargo is building @alexcrichton -- is there a chance this is a Cargo bug? Or am I misreading/misinterpreting this output? Full log for the coretest compile: https://gist.github.com/Mark-Simulacrum/8121483a4484fe2477d9af4adb47d9cc
currently:
|
Hm this does indeed look fishy! I think your diagnosis of rebuilding core is correct and I'm not sure why. I can't quite figure it out from the logs so I'm gonna dig in locally as well |
There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in rust-lang#5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717
Ok that bug should be fixed by rust-lang/cargo#5669 (confirmed locally) and once that Cargo PR lands we'll need to backport it and then make a new beta to update to here |
Fix avoiding a rebuild when moving around a workspace There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in #5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717
There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in rust-lang#5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717
Fix avoiding a rebuild when moving around a workspace This is a backport of #5669. There's a case where Cargo will recompile a project even if the fingerprint looks like it's fresh, when some output files are missing. This was intended to cover the case where an output file was deleted manually or otherwise messed with. The check here was a bit too eager, however. It checked not only the actual output destination of the compiler but *also* the location that we hard link the output file up to. Due to recent changes in #5460 we don't always create the hard links for path dependencies in the top-level dir, and this meant that if the library were compiled and then tested later on the test may recompile the original library by accident. The fix in this commit is to cease looking for the hardlink if it exists or not. This way we only check for the presence of the output file itself and only recompile if that file is missing. The reason for this is that we unconditionally relink files into place whether it's fresh or not, so we'll always recreate the hard link anyway if it's missing. cc rust-lang/rust#51717 r? @alexcrichton
Previously Cargo would hardlink all the dependencies into the "root" as foo.dll and the `toplevel` array would get populated with these, but that's no longer the case. Instead, cargo will only do this for the final artifacts/final libraries. Rustbuild is updated to continue looping through the artifacts mentioned instead of early-returning. This should fix the bug. @alexcrichton found the cause of this and suggested this fix.
@bors: r+ |
📌 Commit 3d68774 has been approved by |
☀️ Test successful - status-appveyor, status-travis |
No description provided.