如何在LSP中实现上下文感知的Go to Implementation功能？

在Rust代码中，调用泛型转换方法时，Go to Implementation功能无法直接跳转到具体的类型实现：

struct A {}

struct B {}

impl From<A> for B {
    fn from(a: A) -> Self {
        B{}
    }
}

fn fun() -> B {
    let a = A{};
    a.into() // 光标在此处
}

期望行为：光标放在a.into()上执行Go to Implementation时，直接跳转到From<A> for B中的from方法定义，查看A到B的具体转换逻辑。

实际行为：跳转到标准库中Into trait的泛型默认实现：

// From implies Into
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_const_unstable(feature = "const_convert", issue = "88674")]
impl<T, U> const Into<U> for T
where
    U: ~const From<T>,
{
    /// Calls `U::from(self)`.
    ///
    /// That is, this conversion is whatever the implementation of
    /// <code>[From]&lt;T&gt; for U</code> chooses to do.
    fn into(self) -> U { // 跳转到此处
        U::from(self)
    }
}

虽然这个结果符合语法定义，但丢失了当前的类型上下文（T=A、U=B），无法直接从这个泛型实现跳转到对应的具体From实现。我们期望编辑器能：

• 临时显示当前的类型绑定上下文作为内联提示；
• 下次执行Go to Implementation时，利用该上下文直接跳转到具体的From<A> for B实现。

核心疑问：实现这类上下文感知的跳转是否需要修改LSP协议？还是协议中已有特性支持处理这类泛型场景？

结论：不需要修改LSP协议，现有协议已支持通过类型上下文实现精准跳转 #

LSP的textDocument/implementation请求本身并没有限制只能返回语法层面的直接定义，关键在于语言服务器的实现是否做了类型驱动的实现查找：

• 类型解析是核心：语言服务器在处理跳转请求时，完全可以先解析当前位置的类型信息——比如在这个例子中，确定调用into()的变量a类型是A，返回类型是B，进而推导出实际生效的是From<A> for B的实现。
• 利用现有协议结构返回精准结果：LSP的Location和LocationLink类型允许返回任意符合条件的实现位置。语言服务器可以直接返回From<A> for B中from方法的位置，而不是只返回泛型Into trait的默认实现；甚至可以同时返回两个位置，让用户选择优先跳转的目标。
• 上下文保留的实现方式：对于“跳转后保留类型上下文，下次直接跳转到具体实现”的需求，也不需要修改协议——编辑器或语言服务器可以在第一次跳转时缓存当前的类型绑定信息（T=A、U=B），当用户在泛型实现的U::from(self)处再次执行Go to Implementation时，直接利用缓存的上下文找到对应的具体实现。

现状与优化方向 #

目前部分语言服务器（比如Rust的rust-analyzer）可能默认只返回泛型 trait 的定义，但这是实现层面的选择，而非协议限制。通过优化语言服务器的类型分析逻辑，就可以实现上下文感知的精准跳转，无需改动LSP协议本身。

内容的提问来源于stack exchange，提问作者Michał Trybus