Change:
// On MSVC we have to use the fallback mode, because LLVM doesn't // lower variant parts to PDB. return cx.sess().target.target.options.is_like_msvc <del> || llvm_util::get_major_version() < 7; </del> <ins> // LLVM version 7 did not release with an important bug fix; // but the required patch is in the LLVM 8.  Rust LLVM reports // 8 as well. || llvm_util::get_major_version() < 8; </ins> } // Describes the members of an enum value: An enum is described as a union of

Discussion:
Initial issue: Steps to reproduce: The master branch can be built without rustc crashing on Gentoo and on Travis (Ubuntu 14.04.5 LTS). UPD: I've tried to build it too and I have the same error. Looks like something wrong with the Arch's rustc. Because if we use the one installed via - everything is ok. UPD: it can be fixed by disabling the LTO, which is enabled by default for .
Arch uses this build config for packaging fwiw:
Arch's build uses the system LLVM, while rustup's uses a bundled one, so the problem is probably due to an LLVM bug that's only present in Arch's version.
Tentatively labeling as I-unsound due to "invalid memory reference".
That's how LLVM asserts look when built without debug check enabled.
Could you please provide a backtrace for the segfault?
How can I do this?
set as an environment variable that your packagemanager will respect
It doesn't make any difference. I've also tried , but nothing interesting there either. Looks like was stripped.
I'm not sure what the canonical way to do this, but I'd just take the rustc command cargo printed out and run it under gdb via . Then and once it crashes .
won't show anything because doesn't panic. Backtrace from crashed thread in Arch:
Doesn't look familiar to me, maybe has seen this trace before?
This is also downstram tracked for archlinux () and NixOS ()
Seems to be fixed by backporting:
I'm investigating this for Fedora too: Thanks for identifying those patches -- I will definitely try that next!
I confirmed that the discriminator patch fixes it, thanks again! That's already in rust/src/llvm, of course. The remaining question here is whether rustc should disable the new enum DWARF for external LLVM7, as I had bisected this to . Or we can just let this issue serve as notice that this LLVM patch is needed for those that use external LLVM.
If that's going to be a requirement, it feels really disingenuous for LLVM 6 be the claimed minimum supported LLVM version. The earliest actually supported upstream release should be what actually checks for, and then if distros using older versions are okay with patching their LLVM, they can just disable the version check.

(And if that's going to be supported, it would be nice to keep some kind of list of patches that are required for those.)
The code in rustc has a fallback for earlier versions of LLVM. The problem here, instead, is that the fallback is not used by LLVM 7, but unfortunately LLVM 7 was released without a necessary bug fix. Changing the fallback to check for "LLVM = 8 or Rust LLVM" would be fine. See
I have a patch for this, will submit shortly.
The main issue with the patch is that if your system LLVM has the fix, then you'll have to patch rustc to back out this workaround; or else have worse debuginfo for enums.
Yeah, it's not obvious what the right answer should be. But since this causes a hard SIGSEGV, it probably is better to take the conservative stance, assuming LLVM7 is unpatched. I will plan on patching Fedora rustc to re-enable this, having patched LLVM already.