debuginfo: Variables in generic functions should have generic type.

[michaelwoerister]

As per 3.3.7 Function Template Instantiations of the DWARF 4 specification, the template type parameter DIE (debug information entry) should be referenced where it has been used in the source code, as opposed to the DIE for the type that has been substituted for the parameter.

In the context of Rust this would mean that the variable x in the following function should be described as having type T=int instead of just type int:

fn generic_fun<T>(x: T) -> T {
    ...
}

fn main() {
    let s_have = Some(generic_fun(11111));
}

As of PR #8554 generic functions are supported but arguments, return value, locals, etc are described as having their type concrete type instead of "their generic type substituted by their concrete type". That means that debug info loses some information.

This should not pose a big problem to the regular debugging workflow---but I wanted to record somewhere that this issue exists.

[flaper87]

Visiting for triage. It still seems relevant.

[steveklabnik]

Triage: nothing to add.

[steveklabnik]

Triage: same as last year.

[Mark-Simulacrum]

As far as I can tell, this is now fixed, or at least equivalent to output from C++ code. Closing, please reopen if that's not the case.

Apologies for my potentially terrible C++, I'm not really familiar enough to speak to it.

template<class T>
T generic_fun(T a) {
        return a;
}

int main() {
        int test = 5;
        return generic_fun(test);
}

c++ gdb:

(gdb) rbreak generic_fun
Breakpoint 1 at 0x4004f8: file ./test.cpp, line 3.
int generic_fun<int>(int);

fn generic_fun<T>(x: T) -> T {
    x
}

fn main() {
    let s_have = Some(generic_fun(11111));
}

rust gdb:

(gdb) rbreak generic_fun
Breakpoint 1 at 0x68b7: file ./t.rs, line 1.
static i32 t::generic_fun<i32>(i32);

Edit: I double checked, and technically, I don't see this as being fixed--whatis x in generic_fun still prints just i32, not T=i32. However, the same is true of the output from generic_fun in both clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) and g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609. So I'm going to say that what we're doing is probably... correct? I'm not sure if there's some way that we should be adding more information...

[michaelwoerister]

Yes, what we are doing here is not really wrong (otherwise the issue would not have stayed unfixed for so long).
Did you look at the DWARF that various compilers generate? I can imagine that they omit this information because it's not used much and just takes up space.