Symbol names for monomorphized trait impls are not stable across crates

[Kha]

In the spirit of #32554:

crate A:

pub trait Foo {
    fn foo<T>();
}

pub struct Bar;

impl Foo for Bar {
    fn foo<T>() { }
}

pub fn bar() {
    Bar::foo::<Bar>();
}

crate B:

extern crate A;
use A::*;

fn bar2() {
    Bar::foo::<Bar>();
}

A.ll:

define internal void @"_ZN27_$LT$Bar$u20$as$u20$Foo$GT$3foo17hde2cfe0cb82f67ddE"() unnamed_addr #0 !dbg !12 {

B.ll:

define internal void @"_ZN33_$LT$A..Bar$u20$as$u20$A..Foo$GT$3foo17he9b727db8600b5deE"() unnamed_addr #0 !dbg !13 {

IOW, A uses the encoding of <Bar as Foo>::foo, while B uses <A::Bar as A::Foo>::foo. The issue seems to be that while symbol names correctly use ctxt::absolute_item_path_str, that function indirectly calls ctxt::item_path_str via e.g. TraitRef's Display implementation.

cc @nikomatsakis @michaelwoerister

[nikomatsakis]

I think that calling absolute_item_path_str is wrong. That method is intended for user output (as the comment says).

[nikomatsakis]

If you look in back::symbol_names, you will see the SymbolPathBuffer, which is what we ought to be using. Not sure how we wind up using the wrong thing exactly though.

[michaelwoerister]

@Kha Good catch.
@nikomatsakis The problem is here:

rust/src/librustc/ty/item_path.rs

Line 221 in c9f1501

buffer.push(&format!("<{} as {}>",

[nikomatsakis]

@michaelwoerister ah, I see, yes, that makes sense. I guess the problem is that we don't have a way to serialize type names that is cross-crate safe. We should try to keep the "spirit" of that rule working though since it'd be nice to get those paths in the symbol names.

[michaelwoerister]

This should be fixed by @eddyb's metadata PR.

[Kha]

Using a global variable, interesting... well, I didn't think of that solution 😄 .

[michaelwoerister]

@Kha It's just a thread-local at least :P

[eddyb]

I think we can improve on the situation by moving to a scheme where we dump types in a structured, but simpler, manner than the current printing logic, and then we can even reuse parts of C++ mangling schemes to get smaller symbols and cleaner c++filt output, at the same time.

[michaelwoerister]

@eddyb yes, please!

[michaelwoerister]

This should be fixed since #33602 landed.

[nikomatsakis]

Removing from milestone since this is just needs-test now.