llvmPackages_16: 16.0.1 -> 16.0.5

[willcohen]

Description of changes

Bumped the default.nix version to the latest point release.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.05 Release Notes (or backporting 22.11 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.

[alyssais]

What needs to be done before this is ready to merge?

[willcohen]

@alyssais nothing in particular, I've just never had a PR on llvm before and didn't want to jump the gun before someone looked at it!

[willcohen]

Separately, @RaitoBezarius, based on #235216, looks like keeping emscripten up to date will occasionally require more backports from LLVM tip to stable. This PR won't get 3.1.40 working, but hopefully the next point release will.

[willcohen]

@RaitoBezarius as noted in #235216, I spoke too soon -- while 3.1.39 built fine already, further attempts to use it and build other things on staging ran into some LLVM issues. I think the backports from 17 to 16 will be necessary to stabilize that for staging, and those are themselves dependent on this landing, so I think this is ready to go now.

For whatever it's worth, emscripten's policy is only to target tip-of-tree LLVM. Keeping llvm_git perpetually up to date just for emscripten strikes me as more challenging than occasional backports. I tried to note that these particular patches are for emscripten -- once the new version stabilizes and emscripten moves on, I think they can be removed. I did submit a backport request which might land in LLVM 16.0.5, but the emscripten maintainers did note that they're skeptical that LLVM will want to include new flag functionality in an old stable branch.

[alyssais]

@ofborg build llvmPackages_16

[willcohen]

Bumping to 16.0.5, which was just released and will be the final point release on the 16 branch. This will unblock #235216 once landed.

Also, retargeting to staging-next to try to catch the #235556 train. Could also retarget to master, but it'd be good to unbreak what's a little broken with emscripten 3.1.39 on staging-next.

[vcunat]

Uh, I was too trusting. It won't apply patches, let alone build and work.

[vcunat]

Reverted for now. Changes like this can go directly to master, by the way, but they should get at least some basic testing before merging. (I incorrectly assumed they have, in this case)

[willcohen]

Apologies — I didn’t do a full rebuild on staging but I can say that this did build locally for me when testing on top of master, at least for Darwin. Will figure out what broke and submit a new PR with fixed patches.

[vcunat]

I don't expect the branch changed that, but this amount of rebuilds is small enough to merge directly to master and avoid such complications.

[willcohen]

New version of this on #235624 to address the need for revert.