Symbol ambiguity with polymorphization and new mangling scheme

[davidtwco]

rustc will not currently bootstrap with -Zsymbol-mangling-version=v0 and -Zpolymorphization=on due to the following issue:

Consider the following example:

// build-pass
// compile-flags: -Zpolymorphize=on -Zsymbol-mangling-version=v0

pub(crate) struct Foo<'a, I, E>(I, &'a E);

impl<'a, I, T: 'a, E> Iterator for Foo<'a, I, E>
where
    I: Iterator<Item = &'a (T, E)>,
{
    type Item = T;

    fn next(&mut self) -> Option<Self::Item> {
        self.find(|_| true)
    }
}

fn main() {
    let mut a = Foo([(1u32, 1u16)].iter(), &1u16);
    let mut b = Foo([(1u16, 1u32)].iter(), &1u32);
    let _ = a.next();
    let _ = b.next();
}

..which produces the following error:

error: symbol `_RNCNvXCs4fqI2P2rA04_19impl_param_manglingINtB4_3FooppENtNtNtNtCsfnEnqCNU58Z_4core4iter6traits8iterator8Iterator4next0B4_` is already defined
  --> src/test/ui/polymorphization/impl-param-mangling.rs:13:19
   |
13 |         self.find(|_| true)
   |                   ^^^^^^^^

error: aborting due to previous error

(unmangled: <impl_param_mangling::Foo<_, _> as core::iter::traits::iterator::Iterator>::next::{closure#0})

Polymorphisation correctly determines that I and E are unused and that T is used in the closure (T is used by the argument). Therefore, multiple copies of this closure can be generated by polymorphization for each instantiation of T - however, this is not encoded in the mangling for the closure, which triggers assert_symbols_are_distinct.

[tesuji]

cc @eddyb as maintainer of new mangling scheme.

[eddyb]

Polymorphisation correctly determines that I and E are unused and that T is used in the closure (T is used by the argument).

Incredible, I wish I thought of this when the polymorphization work was ongoing, I guess I was overfocusing on shims.

So the problem is T is an alias for I::Item, not an "independent variable", the only reason it appears to work in other situations is the trait system is feeding you the value of T. Probably the simplest hackaround is to mangle trait impl "parameters".

But it seems more prudent to consider any parameter not named in the TraitRef as depending on all parameters that do appear in the TraitRef (or you can try to do something more clever by looking at the where clauses).