Mangling of closure names regressed into printing compiler internals.

[eddyb]

In an IR dump by @frankmcsherry, this mangled function name can be spotted:

_ZN1074_$u5b$closure$SP$DefId$u20$$u7b$$u20$krate.$u20$17$C$$u20$node.$u20$DefIndex$LP$1064$RP$$u20$$u7d$$u20$0.collections..vec..Vec$LT$$LP$timely..progress..nested..product..Product$LT$timely..progress..nested..product..Product$LT$timely..progress..timestamp..RootTimestamp$C$$u20$u64$GT$$C$$u20$u64$GT$$C$$u20$collections..vec..Vec$LT$collections..vec..Vec$LT$$LP$$LP$u32$C$$u20$u32$RP$$C$$u20$i32$RP$$GT$$GT$$RP$$GT$$C$$u20$1.radix_sort..RadixSorter$LT$$LP$$LP$u32$C$$u20$u32$RP$$C$$u20$i32$RP$$GT$$C$$u20$2.rc..stable_rc..Rc$LT$$u5b$closure$SP$DefId$u20$$u7b$$u20$krate.$u20$17$C$$u20$node.$u20$DefIndex$LP$1719$RP$$u20$$u7d$$u5d$$GT$$C$$u20$3.rc..stable_rc..Weak$LT$core..cell..RefCell$LT$differential_dataflow..collection..trace..Trace$LT$u32$C$$u20$timely..progress..nested..product..Product$LT$timely..progress..nested..product..Product$LT$timely..progress..timestamp..RootTimestamp$C$$u20$u64$GT$$C$$u20$u64$GT$$C$$u20$u32$C$$u20$$LP$collections..vec..Vec$LT$core..option..Option$LT$differential_dataflow..collection..trace..Offset$GT$$GT$$C$$u20$u64$RP$$GT$$GT$$GT$$u5d$10drop.2263317hdd28099483d4e7b3E

DefId shouldn't be in there, it kinda looks like the fmt::Debug impl instead of a mangling-friendly string.
That suspicion was confirmed by unmangling the name with my rustfilt script:

[closure@DefId { krate. 17, node. DefIndex(1064) } 0.collections::vec::Vec<(timely::progress::nested::product::Product<timely::progress::nested::product::Product<timely::progress::timestamp::RootTimestamp, u64>, u64>, collections::vec::Vec<collections::vec::Vec<((u32, u32), i32)>>)>, 1.radix_sort::RadixSorter<((u32, u32), i32)>, 2.rc::stable_rc::Rc<[closure@DefId { krate. 17, node. DefIndex(1719) }]>, 3.rc::stable_rc::Weak<core::cell::RefCell<differential_dataflow::collection::trace::Trace<u32, timely::progress::nested::product::Product<timely::progress::nested::product::Product<timely::progress::timestamp::RootTimestamp, u64>, u64>, u32, (collections::vec::Vec<core::option::Option<differential_dataflow::collection::trace::Offset>>, u64)>>>]::drop.22633

You can see [closure@DefId { krate: 17, node: DefIndex(1719) }], which is how cross-crate closure types seem to be printed at the moment.

This might be related to @nikomatsakis' changes to how DefIds are represented, or could have been lurking around since the closure reforms.

Originally seen in rustc 1.7.0-nightly (81ae8be 2015-12-09).

[alexcrichton]

I wonder if perhaps #30328 is where this came from?

[eddyb]

@alexcrichton Doesn't look like it, that only affects impls.

[alexcrichton]

Ah oh well, was worth a shot!

[Mark-Simulacrum]

This no longer appear to happen; closures are _ZN8rust_out4main28_$u7b$$u7b$closure$u7d$$u7d$17hc86fb7b1008d9517E in LLVM IR output which unmangles to _ZN8rust_out4main28{{closure}}17hc86fb7b1008d9517E. Not sure if LLVM IR is the IR referred to, though.

[arielb1]

Sure enough. Incremental compilation should prevent this from breaking in the future.