Update nightly rustc to 2018-07-24 #225
Conversation
|
Hi @kennytm, thanks for your PR. I am always getting this kind of PR's to update rustc but unfortunately updating rustc on docs.rs is a little bit more complicated process. After implementing all docs.rs specific changes to upstream rustc, it will be much easier (it's a work in process atm). Currently I need to update my internal rustc and build for 6 different platforms and test latest rustdoc changes to update rustc on docs.rs. So, this PR is only updating rustc that required to build docs.rs. I'll try to update rustc this weekend when I find some free time and after implementing changes to upstream rustc we will be able to use rustup for future updates. |
|
I see, thanks :) |
This code is maybe not as elegant as it could be but should hopefully work? I'm not 100% sure how the crates are built (i.e. how the working directories are built and scoped) so I hope that `rustup` is invoked in the correct directory. If that's not the case, then this can be changed. Additionally I am aware that this is a **work in progress** and further changes are required on docs.rs and the compilers part to make "hot-swapping" versions easier. See rust-lang#225 for more details. This PR addresses rust-lang#228
|
@onur can I (or anyone else) help move this along? The changes to rustc look fairly minor - what needs doing to upstream them? I'm not quite sure what the debian stuff is for, are those changes still needed if the other changes are upstreamed? |
|
One concern here is that the patch can lead to an explosion of different rust versions being downloaded and perhaps taking up diskspace. A second concern is what happens when packages aren't updated and keep referencing very old nightlies. (Nightlies that have long since gone stable.) |
|
That said, supporting multiple versions of rust of course is highly desirable. Especially since -as a Rust newbie- I just uploaded a Rust 2018 package that requires beta which of course breaks docs.rs. Perhaps one could start out with small curated library of rustc versions that are installed on docs.rs. This list presumably would contain a recent stable version (because none of the other channels are guaranteed to work) and one or more flavors of nightly and/or beta. If stable is updated to the latest version and a crate breaks this presumably needs to be addressed by the crate maintainers. If this holds the list only needs to contain one stable. If nightly is updated to the latest version and a crate breaks you could perhaps fall back to the "previously used nightly that didn't yield errors on the crate" in the docs.rs library. So if the Rust compiler library held one stable and two or three nightlies (with buggy nightlies being replaced with less problematic ones) perhaps this could compile enough crates without errors? It would still be useful if a crate could specify that it needed nightly or beta (or stable?). Or perhaps a minimum version required. |
The previous nightly 2018-06-03 suffers from rust-lang/rust#50561, which caused several packages failed to build (see https://github.com/onur/docs.rs/issues/23#issuecomment-397496013). This bug has been fixed on Jun 12th by rust-lang/rust#50617, so we just need to update the nightly beyond this date.