textDocument/typeDefinition should find type definitions, not just definitions

[dpathakj]

Zig Version

0.11.0-dev.1253+fcee1bf99

Zig Language Server Version

0.11.0-dev.117+4423a5f

Steps to Reproduce

zls's implementation for textDocument/typeDefinition is currently the same as textDocument/definition. That's not quite right: instead of finding the definition of whatever is at a given position, zls should either find the definition of that thing's type, if that's possible, or fail if it's a type where that doesn't make sense. (I doubt there's a reasonable answer for, say, a variable of type u32, but I don't know zig all that well yet. At any rate this seems answerable for user-defined types, though harder than the existing 'find definition'.)

The code that makes typeDefinition the same as definition is here.

Here's an example to make this a bit clearer. In the program below, suppose the user's cursor is on myfoo within the last std.debug.print. When the server is asked for textDocument/typeDefinition for that position, the correct answer is somewhere on line 3: the variable myfoo has type Foo, and line 3 is where struct Foo is defined. The current zls will instead point to myfoo's definition on line 8 (assuming you avoid #891).

(That's line 3/8 in terms of typical editors' displayed line-numberings. LSP wire protocol logs in this example will say 2/7 instead, since the protocol apparently uses 0-based indexing. That's evidently what LSP clients expect, since textDocument/definition seems to work fine.)

const std = @import("std");

const Foo = struct { // definition of myfoo's type, aka 'type definition'
    bar: u8,
};

pub fn main() !void {
    const myfoo = Foo{ .bar = 32 }; // ordinary definition of myfoo

    std.debug.print("{}", myfoo);
}

Likewise, querying for the type definition of myfoo from myfoo's declaration within line 8 (say, column 12) should return Foo's definition; right now it just returns the same line, line 8.

There's probably some complexity here when there are multiple types involved; for example, rust-analyzer ends up returning multiple answers in some situations - maybe just when there's a generic involved.

Expected Behavior

zls should either:

1. report that it doesn't have the typeDefinition capability, or
2. correctly return the type definition, and not fall back to the regular definition

Actual Behavior

zls just responds as if the user asked for textDocument/definition; see the example and code link above.

[litaxc]

I second this issue. It is quite confusing that type definition jump to variable definition.