llvmPackages: nixfmt tree

[RossComputerGuy]

Things done

nixfmt the LLVM nix tree as a part of the pre-work for #375431.

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• 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.

[alyssais]

Ack.

[pwaller]

Ack.

[RossComputerGuy]

What's with the ack? I think it's better to just bite the reformatting than wait for a hit from a treewide reformatting PR. Plus, this'll make it easier to deal with some of the next PR's I'm planning on.

[alyssais]

"Ack" is short for "acknowledged" (positively, but not reviewed). See e.g. https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by for a detailed explanation of what an ack is in an open source review context.

[emilazy]

Please add this to .git-blame-ignore-revs to not break git blame. Note that at least one significant change to the formatting is planned and there will be a treewide within the next month or two that formats these anyway (that will modify them regardless due to the planned change) so it may be best just to wait.

[pwaller]

it may be best just to wait.

An alternate view. Fixing the llvm tree doesn't need to be conditioned on whether the rest of the nixpkgs tree is being fixed. If anything it would surely suit the llvm tree to do it at a time convenient for the llvm tree.

If someone starts a PR now which takes time to land; there is a fair chance it ends up having to be rebased through these changes. This could take up some precious cycles from everyone involved in those reviews.

I percieve that there is (relatively) little in flight right now in the llvm tree. I'd always like to minimize the amount of work that gets invalidated. I would push for landing whatever is in flight (and has a good chance of landing without major changes) now as quickly as we can, then land this.

[emilazy]

It won’t be fixed insofar as “not needing another format again” because of the upcoming change to the formatting rules I mentioned. It does mean another entry in .git-blame-ignore-revs for all eternity, but that’s not the end of the world. The nature of the upcoming change means that doing it now might make git blame permanently worse, however, as lines are drastically rearranged and then rearranged back; .git-blame-ignore-revs isn’t perfect (though it’s possible it can handle that case okay; I haven’t tested).

This would also need doing on the 24.11 branch (and that commit adding to .git-blame-ignore-revs on both branches), otherwise backports will be a nightmare. Any pending changes on staging will also cause conflicts unless dealt with. That’s another thing the treewide will handle automatically.

In‐flight work should not pose a problem because of things like #363759 and NixOS/nixfmt#277 (which will have had any kinks ironed out by the time of the treewide format, so it may actually cause less pain to wait).

Anyway, not a hard objection as long as the commit is added to .git-blame-ignore-revs and the branches are handled properly. I’m just saying that the upside is relatively slight and the downsides may outweigh it. Getting the details right to make the process is not a pain is why the first treewide didn’t happen many months ago and why the second is still pending on the one (IIRC) remaining blocker.

[pwaller]

Your comment was persuasive and informative. I didn't realise the formatting rules are changing. If so, I agree we should wait for that to settle.

[RossComputerGuy]

Closing since there's the treewide nixfmt + LLVM refactorings.