rustc: 1.86.0 -> 1.87.0

[winterqt]

https://github.com/rust-lang/rust/releases/tag/1.87.0

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin, nix-build -A fd
• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[winterqt]

(forgot whether we normally backport these or not (we don't, it seems) -- but I guess it may be nice to get it into 25.05...?)

[dotlambda]

How about adding rust_1_87 in a PR targeting master and change the default in a PR targeting staging?

[winterqt]

Good idea, though it seems like we usually don’t do that until something that requires it comes up. If we were doing another staging cycle before the release then I’d backport it, but… dunno.

[alyssais]

Good idea, though it seems like we usually don’t do that until something that requires it comes up.

Indeed. It doesn't seem like there's anything earth-shattering in this release that makes it particularly urgent to have this in stable (where we'd then be forced to keep it around for six months).

[alyssais]

Diff LGTM.

[nixpkgs-ci]

Backport failed for release-25.05, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-25.05
git worktree add -d .worktree/backport-407444-to-release-25.05 origin/release-25.05
cd .worktree/backport-407444-to-release-25.05
git switch --create backport-407444-to-release-25.05
git cherry-pick -x 3b58d0ac8533e58882c9b4e6e2ffe0fc4a300dbf 4efa2ff7a1c0343a0a253fb02c7725d119a4321c 1000a826ebc4b104746cb127852993ca3910efbd

[D3vil0p3r]

Can you create a backport PR to 25.05 for 1.87 rustc version please?

[alyssais]

We don't backport Rust updates, as they can be breaking for packages that use nightly features, of which we have many.

[alyssais]

(When we really need a newer Rust version on stable, e.g. to build browsers, it's added as a new, versioned attribute.)

[adamcstephens]

(When we really need a newer Rust version on stable, e.g. to build browsers, it's added as a new, versioned attribute.)

Do we have a good example or pattern for creating this versioned backport? I've now hit two security important patches that really should be backported, kanidm and fractal, that need a newer rustc. I'd probably suggest 1.88 since that's what the matrix libraries want.

[alyssais]

You can't backport just the security fix, not the changes to use newer Rust features?

[adamcstephens]

In the case of Fractal, they upgraded to the newer version of matrix-rust-sdk which depends on 1.88, but is where the important security fixes come in. So no, there's not really a trivial way to just backport the security fix.

For kanidm, there are multiple dependencies that want 1.87+. While not technically a security fix, we do follow upstream's support lifecycle and backport upgrades. Since it's a security important tool, I'd much prefer to continue to stick to what upstream supports.

[alyssais]

In the case of Fractal, they upgraded to the newer version of matrix-rust-sdk which depends on 1.88, but is where the important security fixes come in. So no, there's not really a trivial way to just backport the security fix.

Hmm yes, it's annoying that we don't have a good way to patch dependencies.

---

Anyway, if you do need to backport a rustc, look at past Firefox backports, I guess.