rustc: use 1.82.0 binary to bootstrap rustc 1.82.0

[skeuchel]

This uses the upstream version 1.82.0 binary to bootstrap the rust compiler of the same version instead of the binary of the previous version on riscv64-linux. The reason is that the older 1.81.0 cannot bootstrap the new version for this platform as discussed in rust-lang/rust#129268. This is a temporary fix that is only necessary for this version and it only applies to native compilation, not to cross compilation.

Edit: Update it for all platforms.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
  • riscv64-linux
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[skeuchel]

But also, maybe it would be better to just use 1.82.0 on all platforms for this release, to avoid confusing divergences like this? I'm pretty sure the comment above that says "MUST be one version prior" is not accurate, because my understanding is that rustc also always supports building a released compiler with itself.

Maintainers what do you think?

[alyssais]

FWIW while I'm not listed as a maintainer, that's basically an accident. I'm generally the one who handles rustc upgrades and a lot of other rust stuff.

Apparently in 2017 we were told that we should be using the previous version of rustc, not the current one. @workingjubilee do you know if that's still what we should be preferring in general?

[workingjubilee]

But also, maybe it would be better to just use 1.82.0 on all platforms for this release, to avoid confusing divergences like this? I'm pretty sure the comment above that says "MUST be one version prior" is not accurate, because my understanding is that rustc also always supports building a released compiler with itself.

Correct, the Rust compiler must be able to build itself.

[workingjubilee]

In 2017, our usual flow for bootstrapping the compiler was different, so it could have been much rockier, and it has always been touchy on 32-bit.

Nowadays, for development purposes, we build the standard library with the last beta version. From release to release, that means "the last version". This was easier to standardize on, and have everyone reuse it. Then we build the compiler with the beta + new library. Then it builds its own library again to complete its sysroot.

Then, after building the compiler with the beta, there is another build with the new compiler. In many cases there are no practical differences.

[skeuchel]

So if upstream now ensures that each version can build itself, then I propose to change the bootstrap accordingly. I have updated the PR to do so.

[alyssais]

Could you put an explanation of why we're making this change in the commit message please?

[winterqt]

Thank you!