Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monomorphised go to definition #8373

Open
DJMcNab opened this issue Apr 6, 2021 · 1 comment
Open

Monomorphised go to definition #8373

DJMcNab opened this issue Apr 6, 2021 · 1 comment
Labels
A-ide general IDE features C-feature Category: feature request E-hard fun A technically challenging issue with high impact S-actionable Someone could pick this issue up and work on it right now

Comments

@DJMcNab
Copy link
Contributor

DJMcNab commented Apr 6, 2021

Ideally, we should be able to follow a chain of go-to definitions to drill down to the specific implementations relied upon.

This would happen after #4558 is resolved.

One example is give in #2541 (comment)

Larger example I often find myself trying to work out what code gets called in a specific instantiation of a generic function, e.g. in
trait Flob {
    fn flobulate(self); //<-E
}
impl Flob for u32 {
    fn flobulate(self) { //<- D
        some::cool::implementation()
    }
}
fn exec<T: Flob>(val: T) { // <-B
    val.flobulate(); // <-C
}
fn main() {
    exec(10u32); // <-A
}

I would click go to definition on exec at A, which would take me to B. I'd then click go to definition of flobulate at C, which I would want to take me to D, but instead takes me to E. If I want to find out what the specific implementation of flobulate actually does, I have to drop what I'm doing to track this manually. This means tracking which types are used in the instantiation I am interested in, trace them though (following associated types manually) and then track down the specific trait implementation which is actually used.
This is not fun, and feels like something rust-analyzer could help with.

My proposed user experience would be that the generics would be tracked, in a sense monomorphising the generic types upon go to definition.

My super high level implementation suggestion would be:
When you follow a go to definition on a generic function, the generics the function is called with are pushed onto a stack somewhere. Ideally, going back using mouse 4 or alt-left would pop this stack. These generics would then be used to get the specific type information for the first step as far as possible. These types could also be displayed as inlay hints next to the generic declaraction, e.g.

fn exec<T: Flob{inlay hint: =u32}>(val: T) { // <-B
    val.flobulate(); // <-C
}

in my example and

impl<T: fmt::Display + ?Sized{inlay hint: = i32}> ToString for T {
    fn to_string(&self) -> String {
       /* ... */
       buf.write_fmt(format_args!("{}", self))
       /* ... */
    }
}

in the example from #2541 (comment)

Most of this is copied from my comment on zulip, where further related discussion might occur.

@flodiebold
Copy link
Member

CC #7890, something analogous would also be nice for macros.

@jonas-schievink jonas-schievink added E-hard fun A technically challenging issue with high impact S-actionable Someone could pick this issue up and work on it right now labels Apr 6, 2021
@Veykril Veykril added the A-ide general IDE features label Nov 11, 2022
@Veykril Veykril added the C-feature Category: feature request label Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ide general IDE features C-feature Category: feature request E-hard fun A technically challenging issue with high impact S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

4 participants