llvm 5: 5.0.0 -> 5.0.1

[dtzWill]

NEEDS MORE TESTING BEFORE MERGE!

• Darwin might want a vote.
• Linux isn't fully tested yet-- my laptop's bravely doing what it can but isn't done yet O:).

Motivation for this change

New minor LLVM release!

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[dtzWill]

Actually my machines run out of memory (?) when trying to use nox-review O:). On a 32GB node.

[dtzWill]

None of the following is relevant to this PR!

Turns out huge rebuilds and nox-review and nix-build don't play nice, resulting in a PR I just filed against nox. Weeee.

---

Looks like memory exhaustion was due to boehmgc, message below :(. Chasing a bit suggests perhaps building with large config enabled might help?

Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS

Update:

Looks like boehmgc's "small" (default) config is at 8GB which matches that I'm seeing before nix reports the above error.

Update 2:

Looks like the sort of command nox-review uses (nix-build -A attr1 -A attr2 ...) causes Nix to use a lot of memory!
Seeing the memory error (8GB used) when using only ~10% of the attributes it generates to review this PR O:).

Replacing the command with a single expression with all the attributes in an array fixes the memory usage!

Might not be perfect, but for completeness here's what I mean:

$ nix-build -E - <<EOF
  let e = import /home/will/.nox/nixpkgs { };
  in [
    e.openscad
    e.kdeFrameworks.kidletime
    e.python36Packages.secretstorage
    e.cherrytree
    e.firefoxWrapper
    e.haxe
    e.virtmanager
    e.ibus-engines.libpinyin
    e.kdeApplications.l10n.zh_TW.qt4
    e.toxic
    e.inkscape
    e.kdeApplications.akonadi-contacts
    e.kdeApplications.l10n.el.qt4
    e.gnome3.gnome-bluetooth
    e.moonlight-embedded
    e.eid-viewer
    e.cataclysm-dda
    e.libvirt
    e.libsForQt5.modemmanager-qt
    e.cataclysm-dda-git
    e.debian_devscripts
    e.hash-slinger
    e.fcitx-engines.unikey
    ...
    e.kdeApplications.konsole
    e.zeal
    e.xfce.xfce4_pulseaudio_plugin
    e.libsForQt5.libdbusmenu
    e.dotnetPackages.OpenNAT
    e.seyren
    e.jing
    e.gnome2.libgnomeprint
    e.asciidoc-full-with-plugins
    e.libsForQt5.kitemviews
    e.jfbview
    e.sound-juicer
    e.envoy
    e.git-crypt
    e.dleyna-renderer
    e.libsForQt56.libopenshot
    e.synthv1
    e.numix-sx-gtk-theme
    e.kdeApplications.libkcddb
]
EOF

[vcunat]

llvmPackages and mesa_noglu build OK; clang compiles hello-world.

It would be nice if someone tested Darwin a little before we unleash Hydra.

[dtzWill]

Ping! @LnL7 is this something you can look into, or maybe ping someone who can? Thanks! :D

[orivej]

I have tested on Darwin by building llvm_5, clang_5 and ycmd (it uses llvmPackages_5). Thanks for the update!

[LnL7]

Forgot about this, thanks for the ping 😄

[vcunat]

I initially forgot – the Darwin stdenv uses an older branch than 5, so the Darwin impact should be minimal anyway...

[LnL7]

Yeah, perhaps we should start looking at switching the default.