Change:
<ins> #![feature(rustc_attrs)] // This test is the same code as in ui/issue-53912.rs but this test checks that the symbol mangling // fix produces the correct result, whereas that test just checks that the reproduction compiles // successfully and doesn't segfault fn dummy() {} mod llvm { pub(crate) struct Foo; } mod foo { pub(crate) struct Foo<T>(T); impl Foo<::llvm::Foo> { #[rustc_symbol_name] //~^ ERROR _ZN11issue_609253foo36Foo$LT$issue_60925..llv$6d$..Foo$GT$3foo17h059a991a004536adE pub(crate) fn foo() { for _ in 0..0 { for _ in &[::dummy()] { ::dummy(); ::dummy(); ::dummy(); } } } } pub(crate) fn foo() { Foo::foo(); Foo::foo(); } } pub fn foo() { foo::foo(); } fn main() {} </ins>

Discussion:
I'm seeing a segmentation fault in the during compilation when compiling with . This is only happening on MacOS (tested on High Sierra and Mojave); it works fine on Ubuntu 16.04. This issue also does not occur without . I haven't been able to make a smaller example for this, but it seems to have started after we renamed the submodule to (). After some investigation, we found that any one of the following changes fix the segmentation fault, but are non-ideal: Add to in the Cargo manifest. Add to in the Cargo manifest. Rename the to something else (e.g., ): this is what seems to have introduced the issue. This is almost certainly related to , but the code example in that issue seems fixed: I'll update this issue with a minimal example when I can come up with one. The faulting command is: thread , stop reason = EXCBADACCESS (code=1, address=0xffffffffffffff41) frame : 0x0000000106a7575d librustccodegenllvm-std::1::function::func&lt;llvm::thinLTOInternalizeModule(llvm::Module&amp;, llvm::DenseMap&lt;unsigned long long, llvm::GlobalValueSummary, llvm::DenseMapInfo&lt;unsigned long long, llvm::detail::DenseMapPair&lt;unsigned long long, llvm::GlobalValueSummaryconst&amp;)::2, bool (llvm::GlobalValue const&amp;)::operator()(llvm::GlobalValue const&amp;) + 765 librustccodegenllvm-std::1::function::func<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary, llvm::DenseMapInfo<unsigned long long, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummaryconst&)::2, bool (llvm::GlobalValue const&)::operator(): -0x106a7575d <+765: movzbl 0xc(%rax), %eax 0x106a75761 <+769: andl $0xf, %eax 0x106a75764 <+772: addl $-0x7, %eax 0x106a75767 <+775: cmpl $0x1, %eax Target 0: (rustc) stopped.

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very likely to effectively be a duplicate of , but would be good to confirm (and hopefully fix!).
heh. Can/should we special case in our mangling algorithm to side-step this? (are issues like this perhaps an argument for a non-bijective mangling system, to reduce the chance of painting ourselves into corners here? we really can't plan ahead for all possible lack-of-expressiveness bugs on LLVM's part, though) cc rust-lang/rfcs and
triage: P-high to resolve our short-term response. Leaving I-nominated in hopes that we discuss at triage today.
discussed at T-compiler meeting. Got rough approval from to put in a lint or something to detect offensive symbols as a short-term hack. The right long-term solution will come with the implementation of rust-lang/rfcs (see e.g. PR )
claim Assigning to self to implement lint.
I'm not sure we should throw a lint at this. We can replace the in with , and eixsting demanglers should be able to cope with it. (We should've done this the first time, but because it was affecting rustc at that point, it would've caused further delays)

This example (reduced from ) either crashes LLVM or makes it emit an assertion: I suspect the loops aren't needed, but the control-flow there affects the bug in finicky ways. The name of the module appears to be important and tied to the fact that we end up emitting in a symbol name (because of the ), which gets mangled as (note the two dots). Among other things, changing the we use to mangle , to makes the bug go away. Assertion message (if LLVM assertions are enabled): Stack backtrace for SIGSEGV (if LLVM assertions are disabled): cc
Found the culprit in : LLVM implicitly assumes that cannot show up randomly in symbol names, and rustc breaks that assumption - but LLVM never checks it, so it shares part of the blame here, IMO. Probably the correct thing to do for LLVM is to split the string at the last , instead of the first.
Why are computers
The work around I introduced with the above commit is a proposition of and fixes this issue with the segfault.
Sanitizing to and adding a debug assertion would also be a good idea.