When writing assembly output demangled fn name in comments

[stepancheg]

With this patch --emit=asm looks like this:

; <alloc::vec::Vec<T> as core::ops::index::IndexMut<core::ops::range::RangeFull>>::index_mut
__ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h8ecb05aacf724133E:
    ...
Lcfi2:
    .cfi_def_cfa_register %rbp
    subq    $16, %rsp
;   <alloc::vec::Vec<T> as core::ops::deref::DerefMut>::deref_mut
    callq   __ZN71_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..deref..DerefMut$GT$9deref_mut17heae350c695265f00E

Unlike writing LLVM IR, it is hard to plug into LLVM to output
comments without duplicating large amount of LLVM code (because
LLVM doesn't have hooks, or at least I haven't found them). So it
is implemented by post-processing assembly text.

cc rust-lang/rust-playground#15
cc #42971

r? nagisa

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[stepancheg]

r? @nagisa

[nagisa]

I’m fairly uncomfortable with the current approach, especially knowing that not every target uses ; as a comment separator. At least nvptx uses //, which this PR does not account for.

I’m also fairly uncomfortable with the fact that demangling has a number of failure conditions which could terminate(?) the compilation.

[stepancheg]

I’m fairly uncomfortable with the current approach, especially knowing that not every target uses ; as a comment separator. At least nvptx uses //, which this PR does not account for.

Thanks for the pointer. It is possible to query LLVM for target machine assembly comment string: target->getMCAsmInfo()->getCommentString().

I'll try to do that now, if this approach (post-processing text output) is acceptable.

I’m also fairly uncomfortable with the fact that demangling has a number of failure conditions which could terminate(?) the compilation.

No, they coudn't. If any parse/demangle failed, output simply outputs original line without any comments. Compilation can only be terminated by I/O errror. (Though, parsing is imprecise, and in race cases output may contain incorrect comments).

[nagisa]

The I/O error could leave the “demangled” file half-truncated. It is not atomic. And it will terminate the compilation rather than continuing on. What for? Demangled names don’t seem worth the possible failure.

Is it really worth doing this by default over just asking people to feed their assembly through rustfilt? The LLVM PR was a fairly obvious improvement. This seems to have a bunch of caveats instead.

[stepancheg]

The I/O error could leave the “demangled” file half-truncated. It is not atomic.

It is the same issue, as when writing original, non-demangled asm file.

Is it really worth doing this by default over just asking people to feed their assembly through rustfilt?

I think that's very convenient, especially for people who do not work with rust full time.

Anyway, I understand this solution is far from perfect, so I'm closing this PR until someone comes with better solution.