Switch to bootstrapping from 1.27 #50629
Conversation
|
|
rust-highfive
added
the
S-waiting-on-review
| @@ -2,6 +2,8 @@ | |||
| authors = ["The Rust Project Developers"] | |||
| name = "alloc" | |||
| version = "0.0.0" | |||
| autotests = false | |||
| autobenches = false | |||
There was a problem hiding this comment.
I believe this is right but I'd like confirmation.
| @@ -2,6 +2,8 @@ | |||
| authors = ["The Rust Project Developers"] | |||
| name = "core" | |||
| version = "0.0.0" | |||
| autotests = false | |||
| autobenches = false | |||
There was a problem hiding this comment.
As with alloc I'm not sure about this, but it felt right...
| @@ -19,7 +19,7 @@ | |||
|
|
|||
| use mem; | |||
| use num::Float; | |||
| #[cfg(not(stage0))] use num::FpCategory; | |||
| use num::FpCategory; | |||
| use num::FpCategory as Fp; | |||
There was a problem hiding this comment.
This feels super awkward and I was confused about the original intent.
| trait SliceExt { | ||
| type Item; | ||
|
|
||
| #[stable(feature = "core", since = "1.6.0")] |
There was a problem hiding this comment.
I'm not quite sure how to interpret this -- these I think were removed in stage1+ anyway, but they are marked as stable...
src/libcore/lib.rs
Outdated
| @@ -246,12 +241,9 @@ macro_rules! vector_impl { ($([$f:ident, $($args:tt)*]),*) => { $($f!($($args)*) | |||
| #[path = "../stdsimd/coresimd/mod.rs"] | |||
| #[allow(missing_docs, missing_debug_implementations, dead_code, unused_imports)] | |||
| #[unstable(feature = "stdsimd", issue = "48556")] | |||
| #[cfg(not(stage0))] // allow changes to how stdsimd works in stage0 | |||
There was a problem hiding this comment.
Oh these are actually intended to stay as we permanently, currently, don't want to compile stdsimd in stage (allows for us to tweak it more easily)
| @@ -553,7 +552,6 @@ macro_rules! f32_core_methods { () => { | |||
|
|
|||
| #[lang = "f32"] | |||
| #[cfg(not(test))] | |||
| #[cfg(not(stage0))] | |||
| impl f32 { | |||
| f32_core_methods!(); | |||
There was a problem hiding this comment.
I think the idea is that the macro above would be inlined here but we can always do that in a follow-up
|
@bors: r+ all looks good to me, thanks @Mark-Simulacrum! We can continue to file follow-up cleanups for the remaining things |
|
📌 Commit 4e77523 has been approved by |
bors
added
S-waiting-on-bors
|
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- |
bors
added
S-waiting-on-author
|
I can't really tell exactly what the problem here is, I'll have to dig in deeper. A few other things of note: Periodically, I get the error below. I think this happens any time I recompile without recompiling the rustc library. Logging shows that the librustc-...rmeta file is rejected due to metadata. I am somewhat suspecting that a change to metadata encoding/decoding is causing this to occur for sysroot crates, but can't come up for a good reason why that would be the case. I don't immediately see anything in the changelog since last stable to rustc_metadata that could cause this... I'll dig more into this tomorrow and over the weekend, but I have not come up with a good reason why this would happen. |
src/Cargo.lock
Outdated
| @@ -1565,7 +1565,7 @@ dependencies = [ | |||
| "lazy_static 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)", | |||
| "libc 0.2.40 (registry+https://github.com/rust-lang/crates.io-index)", | |||
| "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", | |||
| "rand 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)", | |||
| "rand 0.3.22 (registry+https://github.com/rust-lang/crates.io-index)", | |||
|
Regarding the title... I think you mean "Switch to bootstrapping from 1.27"? 😄 |
Mark-Simulacrum
changed the title
|
Okay, I believe I've tracked down the problem -- caused by #49289, but I'm not entirely sure how to fix it. On stable 1.26, running This appears to have been an intentional change; #40109 wants the new behavior. I've filed rust-lang/cargo#5524 to track a warning being added to Cargo, and pushed up a commit that should fix it in this PR by renaming the rustc binary to rustc_binary. The problem that was hit on CI is fixed in the latest pushed commit; I believe something changed in how Cargo reports crate names and renames |
Mark-Simulacrum
force-pushed
the
stage-step
branch
from
ec368fb
to
f9e3ed9
Compare
|
This completed a basic test run locally so I'm going to go ahead an @bors r=alexcrichton |
|
📌 Commit f9e3ed9 has been approved by |
bors
added
S-waiting-on-bors
|
@bors p=1 -- I'd like to get the version bumped as soon as possible |
|
🔒 Merge conflict |
bors
added
S-waiting-on-author
Mark-Simulacrum
force-pushed
the
stage-step
branch
from
f9e3ed9
to
b43f616
Compare
In rust-lang#49289, rustc was changed to emit metadata for binaries, which made it so that the librustc.rmeta file created when compiling librustc was overwritten by the rustc-main compilation. This commit renames the rustc-main binary to avoid this problem. rust-lang/cargo#5524 has also been filed to see if Cargo can learn to warn on this situation instead of leaving it for the user to debug.
Mark-Simulacrum
force-pushed
the
stage-step
branch
from
1694c66
to
a22af69
Compare
|
@bors r=alexcrichton |
|
📌 Commit a22af69 has been approved by |
bors
added
S-waiting-on-bors
Switch to bootstrapping from 1.27 It's possible the Float trait could be removed from core, but I couldn't tell whether it was intended to be removed or not. @SimonSapin may be able to comment more here; we can presumably also do that in a follow up PR as this one is already quite large.
|
☀️ Test successful - status-appveyor, status-travis |
Following up to rust-lang#49896 and rust-lang#50629. Fixes rust-lang#32110. E0689 is weird.
It's possible the Float trait could be removed from core, but I couldn't tell whether it was intended to be removed or not. @SimonSapin may be able to comment more here; we can presumably also do that in a follow up PR as this one is already quite large.