Linux bump default LLVM to 11

[toonn]

Motivation for this change

#126411 bumps the default version of LLVM for x86_64 Darwin, which is tied to the stdenv. This brings it in line with aarch64-darwin but takes it out of sync with the default LLVM for Linux. This is not ideal because fixes for one LLVM version could introduce failures for another version, which would require introducing branching on the LLVM version to resolve.

This PR builds on #126411 and is currently mostly to get a Hydra evaluation for Linux to see how much work bumping would take.

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 via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.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.

[alyssais]

As we're working on this, I'd like to suggest that we send fixes straight to master/staging as their own PRs where doing so wouldn't break builds on LLVM 7. That should keep PRs small, and make things much easier to review.

[vcunat]

https://hydra.nixos.org/eval/1715423

[toonn]

Looks like there's about 6-7k newly failing builds, this is the comparison I'm using. Looks like the cups patch I already got rid of is the main issue. I will rebase this on the Darwin bump as soon as 2 builds I'm running to check the changes finish.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-macos-monthly/12330/12

[toonn]

Just rebased on staging-next since all the release-related stuff has cooled down and the bump on Darwin seems to have gone into staging-next OK. Here's a new comparison.

[sternenseemann]

Seems like 400 potential new regressions compared to current master? https://hydra.nixos.org/eval/1732639?compare=trunk#tabs-now-fail

[toonn]

@sternenseemann, yep, what number of failures would be considered good enough? Should I rebase this on master or staging-next again to get a more recent comparison? The staging-next evaluation this one is based on has even more failures when compared to trunk.

[toonn]

So, in this staging-next comparison, from ~ two weeks ago, the main cause of failures seemed to be ispc. This has since been worked around in 981170a so I rebased the branch again.

How do we move this forward? Last comparison we had 23 newly introduced failures as compared to staging-next. Is the goal/requirement to introduce 0 new failures?

[vcunat]

No, even staging-next -> master merges don't target zero regressions, though it's nice when they get very low. If it's like 23 and nothing important stands out, I think it's OK to merge to staging and a further round of reduction can be done during staging-next builds.

[toonn]

Ok, so this is the comparison for the previous evaluation.
The only thing that stands out to me is Blender. Which is still failing because of ispc, so I looked for the most recent evaluation where ispc succeeds and started a new evaluation to make sure.

This confirmed that I did indeed break ispc. Turns out when removing the LLVM 11 specific arguments I removed stdenv = llvmPackages_11.stdenv from the arguments for ispc. I was probably thinking about the darwin stdenv too much, which does use LLVM. The next evaluation should have even fewer failures 🤞.

[toonn]

The ispc failure (and Blender) is fixed now. Zcash was also using an LLVM stdenv but seems to work fine with a GNU stdenv so I'm not sure that's still necessary? @vcunat was so kind as to check that webkitgtk_4_1 does indeed build, I'm not sure why it failed on Hydra (OOM?).

I believe this means there's no more serious failures so this is ready for review/testing.

[toonn]

@alyssais, @sternenseemann, @vcunat, I believe this is ready for review.

[sternenseemann]

Haven't checked if relying on the default version in all cases is wise (depends on the package), but probably doesn't matter in the grand scheme of things (every default LLVM update will need careful checking for regressions).

[toonn]

My motivation for using the default is an assumption that most things that explicitly specify LLVM 11 probably do so because the default isn't recent enough.

[jonringer]

According to the hydra eval, most failures are related to the recent python310 bump

# nix-review-tool output
x86_64-linux python3.10-unittest2-1.1.0 | 91
x86_64-linux python3.10-debugpy-1.5.1 | 58
x86_64-linux python3.10-imagecodecs-lite-2019.12.3 | 29
x86_64-linux python3.10-eventlet-0.33.0 | 27
x86_64-linux sybil-2.0.1 | 19
x86_64-linux python3.10-pytest-4.6.11 | 18
x86_64-linux python3.10-semver-2.13.0 | 17
x86_64-linux python3.9-pygame-2.1.0 | 14
x86_64-linux python3.10-tensorflow-tensorboard-2.6.0 | 12
x86_64-linux webkitgtk-2.34.3 | 11
x86_64-linux python3.10-mpi4py-3.0.3 | 9
x86_64-linux python3.10-commoncode-30.0.0 | 9
x86_64-linux python3.10-sanic-21.9.3 | 9
x86_64-linux python3.10-cssutils-2.3.0 | 8
x86_64-linux python3.10-unicodedata2-13.0.0-2 | 7
x86_64-linux python3.10-mocket-3.10.3 | 7

[mweinelt]

Current comparison against trunk looks very good indeed.

[toonn]

Thanks, @jonringer and @mweinelt!