LSP-SourceKit语义标记能力注册失败问题分析

问题背景

在Sublime Text中使用LSP插件与SourceKit语言服务器交互时，发现服务器无法正确注册semanticTokensProvider能力。这个问题主要出现在处理Swift语言项目时，当打开Swift文件后，系统会抛出错误提示，表明无法解码语义标记。

问题现象

当用户安装LSP-SourceKit插件并打开Swift项目文件时，控制台会显示以下错误信息：

Error handling None
Traceback (most recent call last):
  File ".../sessions.py", line 2339, in on_payload
    handler(result)
  File ".../session_buffer.py", line 597, in _on_semantic_tokens_async
    self._draw_semantic_tokens_async()
  File ".../session_buffer.py", line 646, in _draw_semantic_tokens_async
    token_type, token_modifiers, scope = self.session.decode_semantic_token(
  File ".../sessions.py", line 1818, in decode_semantic_token
    types_legend = tuple(cast(List[str], self.get_capability('semanticTokensProvider.legend.tokenTypes')

根本原因分析

经过深入排查，发现问题出在LSP插件的会话管理逻辑中。具体表现为：

1. 能力注册流程缺陷：当SourceKit服务器返回带有documentSelector属性的响应时，LSP插件未能正确处理这种格式的注册请求。

2. 会话缓冲区注册缺失：在_RegistrationData类的check_applicable方法中，虽然调用了sb.register_capability_async方法，但该方法似乎没有实现预期的功能，导致能力注册实际上并未完成。

3. 能力解码失败：由于语义标记提供者能力未能正确注册，当尝试解码语义标记时，系统无法获取必要的标记类型和图例信息，最终导致错误。

技术细节

在LSP协议中，服务器可以通过两种方式声明其能力：

1. 静态声明：在初始化响应中直接提供能力信息
2. 动态注册：通过client/registerCapability请求注册特定能力

SourceKit服务器选择了第二种方式，并附带了documentSelector参数，这导致LSP插件现有的处理逻辑出现纰漏。

解决方案

临时解决方案是在if data.selector分支中添加以下代码行：

self.capabilities.register(registration_id, capability_path, registration_path, options)

这行代码直接调用能力注册方法，绕过了有缺陷的会话缓冲区注册流程，确保语义标记提供者能力能够正确注册到系统中。

影响范围

该问题主要影响：

• 使用SourceKit作为语言服务器的Swift开发者
• 依赖语义标记高亮功能的用户
• 在macOS系统上使用Sublime Text进行Swift开发的场景

预防措施

为避免类似问题，建议：

1. 完善能力注册的测试用例，特别是针对带选择器的动态注册场景
2. 实现完整的会话缓冲区能力注册方法
3. 增加对能力注册状态的验证机制

总结

这个问题展示了LSP插件在处理特定服务器响应时的不足，特别是当服务器使用带选择器的动态能力注册时。通过分析错误堆栈和代码逻辑，我们找出了问题的根源并提出了解决方案。对于使用LSP-SourceKit的Swift开发者来说，理解这一问题的本质有助于更好地诊断和解决类似的语言服务器集成问题。