Go to definition on 5.to_string() should go to the implemention

[jrmuizel]

In rust-analyzer using "go to definition" on the to_string() part of 5.to_string() takes you to:

pub trait ToString {
    fn to_string(&self) -> String;
}

In IntelliJ it takes you to the more useful:

impl<T: fmt::Display + ?Sized> ToString for T {
    #[inline]
    default fn to_string(&self) -> String {
        use fmt::Write;
        let mut buf = String::new();
        buf.write_fmt(format_args!("{}", self))
           .expect("a Display implementation returned an error unexpectedly");
        buf.shrink_to_fit();
        buf
    }
}

[matklad]

This is currently blocked on chalk -- at the moment, it by design doesn't expose the specific trait impl that matches.

[bstrie]

When you say "by design", do you mean that Chalk has announced the intention to never implement such a feature, or merely that such a feature would be desired but is currently not on the roadmap? If the latter, is there a corresponding issue on the Chalk repo?

[flodiebold]

It's an open design problem; as I understood it, @nikomatsakis agreed we need some way to do this, but alluded to having some particular ideas how it should be done (or how it should not be done). You'd have to ask him for details. I don't think there's an issue in the Chalk repo yet, but I may be wrong.

[matklad]

From what I recall, the idea is to keep the core chalk's interface pure, so that you can only ask "does this type implements this traits", and then leave the "trail of evidence" (which you need to actually codegen) to some extra API.

[nikomatsakis]

Hmm, my plan was to treat this as roughly a kind of associated type normalization. In particular, every method in an impl has a unique type, so the idea was that you would effectively be "normalizing" <T as ToString>::to_string and you would get back either a placeholder (we don't know the impl) or the unique type for the function. There probably isn't much work to implement this in chalk exactly, except to kind of extend the idea of "associated types" beyond types to other sorts of associated members.

[flodiebold]

Ah yeah, that's kind of what I imagined since you mentioned normalization. We wouldn't really need one associated item per method though, would we? Except maybe to handle default methods, but that could also be done in a simpler way...

[nikomatsakis]

@flodiebold right, one per method -- basically each thing in the impl, whether it be a type, fn, or whatever, could be normalized.

[waynr]

Is anyone working on this? And if not, anyone willing to provide me a bit of guidance in making something happen here? I'm practically useless without go to definition in my text editor :(