Autocomplete pulls asosciated type

[peku33]

rust-analyzer version: rust-analyzer version: 0.4.1416-standalone (289208b 2023-02-25)

rustc version: rustc 1.69.0-nightly (34e6673a0 2023-02-25)

relevant settings: standard settings, nothing special

I noticed strange autocomplete behaviour under certain conditions.
If I make two traits with assosciated types, bound to each other and one additional assosciated type with generic parameter, the autocomplete seems to pull methods of this trait.

use core::{marker::PhantomData};

pub trait Foo {
    type BarType: Bar<FooType = Self>;
}

pub trait Bar {
    type FooType: Foo<BarType = Self>;
    
    type ParametrizedType: Iterator<Item = [u8]>;
}

struct Test<P: Foo> {
    p1: usize,
    p2: PhantomData<P>,
}

impl<P: Foo> Test<P> {
    fn test(&mut self) {
        // self.??? <<< HERE
    }
}

Autocomplete on self (marked HERE) should probably hint p1 and p2 fields, but instead it hints all methods from ParametrizedType:

If I change Iterator to anything else, it pulls method from this trait.

Also in this case autocomplete is relatively slow, taking a few seconds, instead of being almost immediate.

[lowr]

This is most likely another symptom of rust-lang/chalk#773 (cc #9507). Interestingly, rust-analyzer thinks any type implements Iterator with such traits in scope.

pub trait Foo {
    type BarType: Bar;
}
pub trait Bar {
    type FooType: Foo;
    type ParametrizedType: Iterator<Item = [u8]>;
}

fn foo<T: Foo>() {
    ().$0 // <- Iterator methods are listed in autocompletion
}

Some more speculative technical explanation: It doesn't cause hang anymore thanks to #13728, but it returns Ok(Solution::Ambig) instead which we take as "Yes, the goal holds". We get into the infinite recursion because chalk tries to prove (): Iterator by applying Implemented(<?0 as Bar>::ParametrizedType: Iterator) clause, which results in the same goal expansion explained in rust-lang/chalk#773.