Don't show two different types as the same thing in a single function

[scottmcm]

I noticed this in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/consts/trait.ConstMethods.html#tymethod.scalar_to_backend today:

Those two Scalars are actually different types, however.

It would be nice to detect things like this and show some distinguisher. Maybe value::Scalar and rustc_abi::Scalar -- including enough module context to distinguish -- or something? Or maybe show the crate name?

(Crate name might be good, since a single crate can fix multiple types with the same name, if needed.)

[krtab]

@rustbot claim

(cc @GuillaumeGomez )

[fmease]

Prior art: trimmed_def_paths.

[krtab]

I don't think trimmed_def_paths does exactly what we want, because in our case, we should trim based on what has already been displayed.

MRE

pub mod Foo {
    pub enum E {}
}

pub mod Bar {
    pub enum E {}
}


pub fn f(foo: Foo::E, bar: Bar::E) {}

gives in doc

pub fn f(foo: E, bar: E)

Now the question is, should it be:

pub fn f(foo: E, bar: Foo::E)

pub fn f(foo: Bar::E, bar: E)

or

pub fn f(foo: Bar::E, bar: Foo::E)

[fmease]

I think the latter (or was that a rhetorical question lol?)

[GuillaumeGomez]

I also prefer the latter (whether it's a rhetorical question or not).

[krtab]

I prefer it as well, but as discussed in #122872 this means that there must be two passes to disambiguate: the first one identifies the non ambiguous suffix of the symbol path, and the second one does the actual rendering. Choosing pub fn f(foo: E, bar: Foo::E) allows us to do it in one pass (a sort of "streaming" disambiguation), which makes it easier to generalize: printing functions must now simply take a context and reset it when appropriate. This context can easily be passed along when we match on the constructs.

If we do the two passes solution, the matching/deconstructing code has to be duplicated (or we go for a full visitor pattern?)

[GuillaumeGomez]

What information is missing to force it to be done in two passes? Once you have all names in the same context (ie, function arguments, struct fields, etc), you can check that a same type has the same name or not and there disambiguate. If you don't have a context when displaying, then try generating the name ahead of time if needed in the clean pass?