Consider __ZN4core5slice29_$LT$impl$u20$$u5b$T$u5d$$GT$16sort_unstable_by28_$u7b$$u7b$closure$u7d$$u7d$17hcf92dcf9c48f99dbE.
rustc-demangle properly unmangles this as: _core::slice::<impl [T]>::sort_unstable_by::{{closure}}.
But if some intermediary debugging tool were to assume the more common C++ mangling scheme, and attempt to demangle it as such (à la c++filt), we then end up with: core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::sort_unstable_by::_$u7b$$u7b$closure$u7d$$u7d$::hcf92dcf9c48f99db.
And by then rustc-demangle (silently) does not recognize mangled input, and decides to just output it back, as-is.
While we could submit this kind of issue to rustc-demangle, it could legitimately be deemed out of scope for it.
However, for a CLI convenience tool such as rustfilt, it could be more legitimate to expect it to be more flexible w.r.t. the input it needs to handle.
If adding a "C++ mangler" involves too many deps, that functionality of rustfilt could be --feature-gated, for instance 🙂
Consider
__ZN4core5slice29_$LT$impl$u20$$u5b$T$u5d$$GT$16sort_unstable_by28_$u7b$$u7b$closure$u7d$$u7d$17hcf92dcf9c48f99dbE.rustc-demangleproperly unmangles this as:_core::slice::<impl [T]>::sort_unstable_by::{{closure}}.But if some intermediary debugging tool were to assume the more common C++ mangling scheme, and attempt to demangle it as such (à la
c++filt), we then end up with:core::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::sort_unstable_by::_$u7b$$u7b$closure$u7d$$u7d$::hcf92dcf9c48f99db.And by then
rustc-demangle(silently) does not recognize mangled input, and decides to just output it back, as-is.While we could submit this kind of issue to
rustc-demangle, it could legitimately be deemed out of scope for it.However, for a CLI convenience tool such as
rustfilt, it could be more legitimate to expect it to be more flexible w.r.t. the input it needs to handle.If adding a "C++ mangler" involves too many deps, that functionality of
rustfiltcould be--feature-gated, for instance 🙂