Implement Go To Implementations command

[ahejlsberg]

This PR implements the LSP textDocument/implementation request which enables the Go To Implementations command in VS Code.

[Copilot]

Pull Request Overview

This PR implements the LSP textDocument/implementation request to enable the "Go To Implementations" command in VS Code. This adds functionality to navigate from interface or abstract class declarations to their concrete implementations.

• Adds LSP server capability registration and request handling for implementations
• Implements core implementation-finding logic using breadth-first search through reference entries
• Refactors location conversion code to be reusable between references and implementations

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
internal/lsp/server.go	Adds LSP capability registration and request handler for implementations
internal/ls/findallreferences.go	Implements core implementation search logic and refactors location conversion
internal/ast/ast.go	Simplifies Type() method by removing panic and handling more cases with nil return

[jakebailey]

This seems like it's going to end up biting us at some point when we forget to add a case here; is this required?

[DanielRosenwasser]

Alternatively, Type() (panics) and TryGetType()/TypeOrNil() (returns nil)

[jakebailey]

Well, other than that some nil returning is actually intentional IIRC

[ahejlsberg]

Type() is already optional and we already have logic that always returns nil for some node kinds. Seems fine to just allow it for any node kind. Name() is similar already.

[DanielRosenwasser]

The original had something like the following check before processing as a queue

    if (
        node.parent.kind === SyntaxKind.PropertyAccessExpression
        || node.parent.kind === SyntaxKind.BindingElement
        || node.parent.kind === SyntaxKind.ElementAccessExpression
        || node.kind === SyntaxKind.SuperKeyword
    ) {
        referenceEntries = entries && [...entries];
    }

and idea what that was intended for? I think there was some special handling for not "cascading" beyond the direct superclass

[ahejlsberg]

Yeah, I think it is so that Go To Implementation on say a super keyword only goes to that type and not other types that implement it. Which seems a little odd. Not really sure why you'd want to Go To Implementation on super, as opposed to Go To Definition or Go To Type Definition.

[jakebailey]

I feel like that makes sense, though, since super is basically "do the parent class thing" and so shouldn't jump anywhere else?

[ahejlsberg]

Well, but what does Go To Implementation on something that isn't a type really mean to begin with? I would think of it as go-to-implementation-of-the-type-of-the-thing-i-am-on. And if the type of super is Base, then implementations of Base also includes Derived.

[jakebailey]

My mental model of it is "the implementation of super is code in a parent class's constructor".

[ahejlsberg]

In Strada, Go To Definition on a super() call goes to the constructor code. But Go To Implementation goes to the base class declaration.

[DanielRosenwasser]

Yeah I looked at the test cases and was surprised. Both go-to-definition and go-to-implementation should probably go to the constructor, but instead we go to the base class for go-to-implementation which feels like it is the less-intuitive thing.

[jakebailey]

weirdddd

[ahejlsberg]

I suppose the meaning we ascribe to "implementation" in go-to-implementations is something that implements that type. As opposed to the implementation of a method or constructor.