llvmPackages_{12,13,14,15,16,17,18,19,git}: commonify patches

[RossComputerGuy]

Description of changes

Reduce the number of patches we have by finding duplicates. Modify getVersionFile in common/default.nix to branch to min/max version patches so we only have to keep 1 copy of a specific version of a patch.

Things done

• 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/)
• 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.

[RossComputerGuy]

Swift build failures can be ignored as they are happening on Hydra as well. It looks like it at least passes the patchPhase.

[alyssais]

This is fantastic work — look at all those deletions! Thank you!

I'm just wondering if there's a better way to express it…

[alyssais]

This big nested conditional is not great — I think maybe it indicates that getVersionFile is not the right abstraction. Maybe it'd be better to just have a list of patches for each major LLVM version?

[RossComputerGuy]

Maybe but there's conditional patches and some patches are the same between versions while having different siblings. I was thinking of doing an attr set and have it work like a table but I found it to be simpler to do it this way.

I was thinking of doing a PR to clean up the common default.nix so it wouldn't be as sloppy. Probably in that one, I could have an attr set of versions and values which could be a string or null which then matches into figuring out where that patch will be.

[alyssais]

I was thinking of doing an attr set and have it work like a table

This is what I was thinking of. Was the problem just that you'd have to repeat the patch of a patch multiple times to say that different versions have the same patch? If so, I think that would be easier to understand overall.

[RossComputerGuy]

Maybe, I'm not sure.

[alyssais]

This is still very complicated, but it's better, and maybe there's just not a better way (apart from upstreaming the patches, of course).

Collapsing the attrsets into single lines (if that's allowed by formatting rules) might help, by making it a bit denser.

[RossComputerGuy]

Collapsing the attrsets into single lines (if that's allowed by formatting rules) might help, by making it a bit denser.

Yeah, I originally did that but the formatter changed it.

[RossComputerGuy]

Before we merge, I want to be able to reproduce and fix that CI error. However, I tried and couldn't get it to fail locally.

[RossComputerGuy]

Well, by-name passed so we should be gtg now.

[tomberek]

possible error here?