llvmPackages: llvmPackages_19 -> llvmPackages_21#407738
llvmPackages: llvmPackages_19 -> llvmPackages_21#407738emilazy merged 4 commits intoNixOS:stagingfrom
Conversation
590b859 to
76e297c
Compare
76e297c to
1234428
Compare
1234428 to
042256a
Compare
I have no idea why this is happening and I don't think it's related to anything I changed. It worked before I rebased to resolve conflicts. |
|
Fixed in #409843. |
7eba173 to
1b44f52
Compare
|
Resolved in #436446 |
8435796 to
542c28d
Compare
pkgs/top-level/all-packages.nix
Outdated
There was a problem hiding this comment.
These should presumably be dropped?
There was a problem hiding this comment.
Because it wasn’t there in the previous version, and it pins an old version of LLVM, and the commit description is “rust: track latest LLVM to simplify version bumps”?
There was a problem hiding this comment.
That's because rust has been using LLVM 20, does it support 21?
There was a problem hiding this comment.
I’m confused – if your intent wasn’t to have Rust track the latest LLVM for LLVM 21, then why did you make a commit with the title “rust: track latest LLVM to simplify version bumps” that made Rust track the latest LLVM, in the LLVM 21 bump PR?
These pins appeared at some point during a rebase. I believe Rust always supports the latest LLVM, but if we want to keep Rust pinned to LLVM 20 then we shouldn’t have a commit talking about unpinning it in an LLVM 21 bump PR that doesn’t unpin it. What makes sense to me is dropping the pins here to accomplish the goal of the commit message, but I might be misunderstanding what the intent of the commit was?
There was a problem hiding this comment.
Because that commit was made when this was doing LLVM 20 at first.
There was a problem hiding this comment.
Ah, okay. But then the commit nothing to do with LLVM 21 and has no functional effect now, so why is it in the LLVM 21 bump PR?
I thought that the intent of unpinning LLVM in Rust was to update Rust’s LLVM when we update the default LLVM, so pinning it because we’re updating to 21 instead doesn’t make sense to me. If we want to unpin Rust’s LLVM so that it always matches the default LLVM, then we should want Rust to start using LLVM 21 when we make that the default, right?
There was a problem hiding this comment.
I'm not sure, I'm about to sleep so I can't think. Let's see what rust maintainers think. Maybe @alyssais would have a good idea?
There was a problem hiding this comment.
Rust should just use our default version of LLVM.
|
We’re close to landing the work I did to get this ready for merge but it needs a rebase and the Rust stuff addressing. |
542c28d to
ddc812d
Compare
|
Needs another rebase 😅 |
ddc812d to
cabe58b
Compare
|
Fixed, hopefully that's the last time I have to rebase this PR. |
|
Yeah, there’s still fixes in the pipeline but now that we have the Darwin system libc++ PR merged |
|
Bisect says that cabe58b
|
|
Now that |
Things done
Bump the global LLVM version. Tested builds:
firefoxmesarustcBuilt on platform(s)
For non-Linux: Is sandboxing enabled in
nix.conf? (See Nix manual)sandbox = relaxedsandbox = trueTested, as applicable:
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 usageTested basic functionality of all binary files (usually in
./result/bin/)Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
Fits CONTRIBUTING.md.
Add a 👍 reaction to pull requests you find important.