Change:
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)

Discussion:
// for ':' and '-' '-' | ':' => self.path.temp_buf.push('.'), <ins> // Avoid segmentation fault on some platforms, see #60925. 'm' if self.path.temp_buf.ends_with(".llv") => self.path.temp_buf.push_str("$6d$"), </ins> // These are legal symbols 'a'..='z' | 'A'..='Z' | '0'..='9' | '_' | '.' | '$' => self.path.temp_buf.push(c),

<ins> // compile-pass // This test is the same code as in ui/symbol-names/issue-60925.rs but this checks that the // reproduction compiles successfully and doesn't segfault, whereas that test just checks that the // symbol mangling fix produces the correct result. fn dummy() {} mod llvm { pub(crate) struct Foo; } mod foo { pub(crate) struct Foo<T>(T); impl Foo<::llvm::Foo> { 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>

<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>

<ins> error: symbol-name(_ZN11issue_609253foo36Foo$LT$issue_60925..llv$6d$..Foo$GT$3foo17h059a991a004536adE) --> $DIR/issue-60925.rs:16:9 | LL |         #[rustc_symbol_name] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>