diff mbox series

[bug#56684,1/3] Bump rust 1.57 -> 1.58

Message ID 0dacb7cb72945f7f6886602c47111661b746cbcc.1658440640.git.jnewsome@torproject.org
State New
Headers
Series [bug#56684,1/3] Bump rust 1.57 -> 1.58 |

Commit Message

Jim Newsome July 21, 2022, 10:01 p.m. UTC 
  From: Jim Newsome <jnewsome@torproject.org>

---
 gnu/packages/rust.scm | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)


base-commit: 5dfc6ab1ab292b87ceea144aa661d0e64c834031

Comments

Jim Newsome July 21, 2022, 10:14 p.m. UTC | #1 
Sorry, forgot to change the initial subject line to [PATCH core-updates].

Happy to follow on to bump further; the latest release is 1.62.1: 
https://github.com/rust-lang/rust/releases

1.60 was the minimum I needed for my own project and since this is my 
first try contributing to guix I figured I'd try getting that in before 
bumping further. Each bump takes a while since I need to build one minor 
version at a time.
Maxime Devos July 22, 2022, 12:08 a.m. UTC | #2 
merge 54439 56684
thanks

You aren't bumping the version but adding a new version of the Rust 
package, the old one is still there. Also, conventionally it is named 
updating in Guix, and a commit message is missing. For examples see the 
git history.

Are all the intermediate steps needed, or could you reduce the number of 
new intermediate packages?

E.g., you could try going directly from 1.57 to 1.60 without 
intermediate steps. If that's possible, it would be less inefficient to 
compile.

Also, there are already patches for updating rust, see 
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54439>. Please look for 
already existing patches before posting duplicates, to avoid double 
work, etc.

Greetings,
Maxime.
Jim Newsome July 22, 2022, 12:47 a.m. UTC | #3 
On 7/21/22 19:08, Maxime Devos wrote:
> You aren't bumping the version but adding a new version of the Rust 
> package, the old one is still there. Also, conventionally it is named 
> updating in Guix, and a commit message is missing. For examples see the 
> git history.

Thanks, got it.

> Are all the intermediate steps needed, or could you reduce the number of 
> new intermediate packages?
 >
 > E.g., you could try going directly from 1.57 to 1.60 without
 > intermediate steps. If that's possible, it would be less inefficient to
 > compile.

Good question. I assumed that each version was only compilable from the 
previous version based on that being how the java compiler works, and 
looking at the chain that's already here. From a quick look I don't see 
any documented policy to that effect, though, so maybe it's worth a try.

> Also, there are already patches for updating rust, see 
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54439>. Please look for 
> already existing patches before posting duplicates, to avoid double 
> work, etc.

Oops! It looks like that is both a bit further along and more ambitious 
than my version. It's also been lingering for a while, while guix's 
version of Rust falls further behind, making me wonder if it's worth 
trying to move things up with something closer to my naive approach in 
the meantime.

Still, I'll take a closer look at that and see if there's anything I can 
do to help that one along.

Thank you for the quick feedback!

-Jim
Jim Newsome July 22, 2022, 1:33 a.m. UTC | #4 
On 7/21/22 19:08, Maxime Devos wrote:
> E.g., you could try going directly from 1.57 to 1.60 without 
> intermediate steps. If that's possible, it would be less inefficient to 
> compile.

I dug into this a bit.

The Rust bootstrapping docs say to use x.py to download the stage0 
compiler. https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html

x.py is a thin wrapper around bootstrap.py: 
https://github.com/rust-lang/rust/blob/master/x.py

bootstrap.py decides what compiler to use as stage0 from stage0.json: 
https://github.com/rust-lang/rust/blob/master/src/bootstrap/bootstrap.py

1.62.1 was compiled with 1.61.0: 
https://github.com/rust-lang/rust/blob/1.62.1/src/stage0.json#L6

1.61.0 was compiled with 1.60.0: 
https://github.com/rust-lang/rust/blob/1.61.0/src/stage0.json#L6

1.60.0 was compiled with 1.59.0: 
https://github.com/rust-lang/rust/blob/1.60.0/src/stage0.json#L6

1.59.0 was compiled with 1.58.0: 
https://github.com/rust-lang/rust/blob/1.59.0/src/stage0.json#L6

1.58.0 was compiled with 1.57.0: 
https://github.com/rust-lang/rust/blob/1.58.0/src/stage0.json#L6

So it looks like each release was compiled with a compiler from one 
feature-release back. In my patchset, I took the highest patch-version 
at each feature-version, since I don't think it makes sense to include 
outdated patch-levels, and it should be safe.

Trying to compile a release with an older compiler than it was 
originally compiled with seems unlikely to go well. It's not explicitly 
stated that it *won't* work, but it seems unlikely that it would, and 
would take a lot of time to verify by trial and error.
Maxime Devos July 22, 2022, 9:07 a.m. UTC | #5 
On 22-07-2022 03:33, Jim Newsome wrote:

> Trying to compile a release with an older compiler than it was 
> originally compiled with seems unlikely to go well. 

It usually works fine for GCC. For Rust, it's a bit less likely given 
the rate at which APIs etc are added, but it's possible that once in a 
while a version can be skipped. Yes, the upstream docs say that X+1 is 
compiled with X, but this is Guix not upstream and upstream doesn't seem 
to care about bootstrapping much, I do not recommend just following the 
method from the docs as a rule or even a recommendation.

(Basically the is-ought problem in another context.)

> It's not explicitly stated that it *won't* work, but it seems unlikely 
> that it would, and would take a lot of time to verify by trial and error. 

? All you need to do is, say, remove 1.58 and bootstrap 1.59 directly 
from 1.57 and see if that compiles and then also give current version in 
guix -> 1.59 a try, etc, if not try 1.57 -> 1.59..

I don't see much trial and error here, there are only a few possible 
combinations.

Yes, it will take some time to compile (rust is big), but this only 
needs to be done once (or zero, the previous patch submitter tried out 
some combinations, those don't have to be done again) and all the 
potential compilation time savings will be shared to everyone, and while 
it is compiling you can still do other things.

If it's too much for your computer if that's what you mean, I suppose it 
would be possible to set up a branch that tries out various combinations 
at ci.guix.gnu.org (it has lots of x86-64 machines).

> Oops! It looks like that is both a bit further along and more 
> ambitious than my version. It's also been lingering for a while, while 
> guix's version of Rust falls further behind, making me wonder if it's 
> worth trying to move things up with something closer to my naive 
> approach in the meantime. 
If you mean ignoring the already existing patch and making a new one 
that does less, this does not incline me to review your patch and 
probably would be frustrating to the original patch submitter, causing 
your patch to linger too.  What I meant is: if possible, go for the 
_original_ patch, improve it with parts of _your_ patch (taking the best 
of both) and submit that as a v2 or such, otherwise just go for the 
original patch and review or test it (e.g., verify it compiles 
reproducibly and share the hash (with "guix hash 
/gnu/store/the-store-item", not the hash in /gnu/store/HASH-...)).

Summarised: double-work tends to cause more lingering, not less.

Greetings,
Maxime.
kiasoc5 Aug. 3, 2022, 6:54 a.m. UTC | #6 
I tried and failed to bootstrap from 1.59 and 1.60 to 1.62.1 directly,
the focus should be on getting Rust 1.61 to build.

It's unlikely that skipping versions for bootstrapping will ever work,
since the latest compiler uses nightly features which might not be
present in lower versions [1]. But it's good to know that it's ok to
skip versions if it does work.

1. https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html
diff mbox series

Patch

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 67dc5cdaf3..dd0f15a95c 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -644,10 +644,14 @@  (define rust-1.56
    rust-1.55 "1.56.1" "04cmqx7nn63hzz7z27b2b0dj2qx18rck9ifvip43s6dampx8v2f3"))
 
 (define rust-1.57
+  (rust-bootstrapped-package
+   rust-1.56 "1.57.0" "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim"))
+
+(define rust-1.58
   (let ((base-rust
          (rust-bootstrapped-package
-          rust-1.56 "1.57.0"
-          "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim")))
+          rust-1.57 "1.58.1"
+          "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")))
     (package
       (inherit base-rust)
       (outputs (cons "rustfmt" (package-outputs base-rust)))
@@ -790,7 +794,7 @@  (define rust-1.57
 ;;; intermediate rusts are built for bootstrapping purposes and should not
 ;;; be relied upon.  This is to ease maintenance and reduce the time
 ;;; required to build the full Rust bootstrap chain.
-(define-public rust rust-1.57)
+(define-public rust rust-1.58)
 
 (define-public rust-src
   (hidden-package