TLDR

Integrate official vscode-languageserver-protocol SDK for LSP types and implement textDocument/didSave notification to enable real-time diagnostics updates after file edits.

Screenshots / Video Demo

N/A — this is an internal infrastructure change. The effect is that LSP diagnostics now update immediately after edits are applied.

Dive Deeper

Problem

Previously, after applying code edits via the Edit tool, LSP diagnostics would not update until the user manually triggered a refresh. This made it difficult to verify fixes immediately.

Solution

1. Official LSP SDK: Added vscode-languageserver-protocol dependency and use official types (InitializeParams, InitializeResult, ServerCapabilities) instead of custom definitions. This ensures type compatibility with the LSP specification.

2. didSave Notification: Implemented notifyDocumentSaved that sends textDocument/didSave to LSP servers after edits. This triggers servers (like gopls, typescript-language-server) to re-read the file from disk and update their diagnostics.

3. Capability Handling:

   • Client now declares synchronization.didSave: true capability
   • Server capabilities are stored from initialize result
   • getSaveCapability properly handles TextDocumentSyncOptions and TextDocumentSyncKind variants

Files Changed

• types.ts: Use lsp.InitializeParams/InitializeResult/ServerCapabilities
• LspServerManager.ts: Store capabilities from initialize result, declare didSave capability
• NativeLspService.ts: Implement notifyDocumentSaved and getSaveCapability
• NativeLspClient.ts: Add notifyDocumentSaved method
• coreToolScheduler.ts: Call notifyDocumentSaved after Edit tool execution

Test Coverage

Added comprehensive tests for notifyDocumentSaved:

• Server with save capability (object with includeText)
• Server without save support (TextDocumentSyncKind.None)
• textDocumentSync as number (Full or Incremental)
• save capability as boolean
• Targeting specific server via serverName parameter
• Graceful error handling when connection fails
• Integration with CoreToolScheduler (edit tool triggers notification)

Known Limitations

• Some LSP servers (e.g., typescript-language-server) do not support textDocument/didSave. For such servers, consider implementing didChange notifications or combining with PR fix(core): add LSP diagnostics caching and document refresh fallback QwenLM/qwen-code#3034's publishDiagnostics caching approach.

Reviewer Test Plan

1. Start qwen-code in a Go project with gopls configured
2. Use the LSP tool to get diagnostics on a file
3. Introduce a syntax error via Edit tool
4. Run diagnostics again - should immediately show the new error
5. Fix the error via Edit tool
6. Run diagnostics again - should show no errors

Verified with gopls

Tested in a single session with edit + diagnostics invoked together:

• Introduced error: unknown field undefinedField in struct literal
• Diagnostics immediately detected: [ERROR] 28:28 (MissingLitField) [compiler]: unknown field undefinedField
• Fixed the error, diagnostics returned: No diagnostics found

This confirms that didSave notification triggers gopls to re-analyze the file and update diagnostics in real-time.

Testing Matrix

Linked issues / bugs

Related to QwenLM#3029 - This PR provides an alternative approach to PR QwenLM#3034 for triggering LSP diagnostics refresh after edits. While PR QwenLM#3034 uses didClose + didOpen with publishDiagnostics caching, this PR uses didSave which is lighter and more semantically correct for post-edit updates. Both approaches are complementary: PR QwenLM#3034's caching is essential for push-only servers (like typescript-language-server), while this PR's didSave provides a cleaner refresh mechanism for edit operations.

🤖 Generated with Qwen Code