基于LSP实现源代码插装的技术问询及调试协议咨询

Great question! You’re already off to a strong start using the Kotlin Language Server for symbol location data—let’s break down how to tackle statement-level instrumentation and address your debugger-related questions.

一、借助LSP遍历方法内语句并实现插装 #

First, a quick clarification: LSP itself doesn’t have a built-in way to directly traverse individual statements within a method. Its strength is exposing structured symbol data, which we can use as a foundation to build our instrumentation logic. Here’s a practical step-by-step approach:

1. Fetch granular symbol data with textDocument/documentSymbol
   You’ve already used workspace/symbol to locate top-level classes and methods, but to dig into their internal statements, you’ll need to call textDocument/documentSymbol on each target file. This request returns a hierarchical tree of symbols in the document—including method bodies, if blocks, loops, assignment statements, and even expressions (depending on how the language server is implemented). Each symbol entry includes a range field marking its start/end positions in the source code.

   Note: Symbol granularity varies by language server. For example, the Kotlin Language Server might return fine-grained statement-level symbols, while others might only expose larger code blocks. You’ll need to test and adapt to your target server’s behavior.

2. Map statement ranges to instrumentation points
   Once you have each statement’s range, decide where to inject your coverage-tracking calls. For most cases, inserting the call at the start of the statement’s range works best (e.g., right before an assignment or loop). For multi-line statements, make sure to target the start of executable code, not leading whitespace or comments.

3. Implement source code modification
   LSP doesn’t handle code edits directly, so you’ll need a separate module to modify source files. Using the range data from documentSymbol, you can:

   • Parse the source file as a string
   • Insert your pre-defined library call (e.g., __track_coverage(__LINE__)) at the calculated position
   • Preserve syntax validity (e.g., maintaining indentation in Python, adding semicolons where needed in Java)

   For more robust edits, pair LSP data with a lightweight AST parser for the target language—this helps avoid breaking syntax when inserting code into complex statements.

4. Handle edge cases

   • Skip non-executable symbols like comments or empty lines
   • Avoid instrumenting synthetic or auto-generated methods
   • Account for language-specific quirks (e.g., JavaScript’s implicit semicolons, Kotlin’s expression-bodied functions)

二、基于LSP插装理念的调试器现状 #

You’re right that VS Code’s debugger doesn’t use LSP—it relies on the Debug Adapter Protocol (DAP), a separate standard built specifically for debugging workflows. Here’s what you need to know:

• Why LSP isn’t used for debugging: LSP focuses on language-aware features like completion, refactoring, and symbol navigation. It doesn’t define the low-level debugging primitives required (e.g., setting breakpoints, stepping through code, inspecting runtime variables).

• The Debug Adapter Protocol (DAP): This is the de facto standard for modern IDE debuggers. It defines a common set of requests and responses between a debugger client (like VS Code) and a debug adapter (which communicates with the target runtime). Key DAP features include:

  • launch/attach requests to start or connect to a debug session
  • setBreakpoints to define breakpoints by source location
  • stepIn, stepOver, continue for controlling execution flow
  • variables requests to inspect runtime state

  Most major debuggers (VS Code, IntelliJ, Eclipse) use DAP, and language-specific adapters (like Java Debug Adapter, Python Debug Adapter) implement the protocol for their respective runtimes.

• LSP + DAP combinations: Purely LSP-based debuggers don’t exist, since LSP lacks debugging semantics. However, some tools combine the two: for example, a language server might expose symbol data to help the DAP resolve breakpoint locations more accurately.

三、额外注意事项 #

• Language server compatibility: Not all language servers implement textDocument/documentSymbol with the same level of detail. You may need to use textDocument/semanticTokens as a fallback for finer-grained token data if documentSymbol is too coarse.
• Performance overhead: Source-level instrumentation can add runtime overhead, especially for benchmarking scenarios. Consider making instrumentation optional or using lightweight tracking logic to minimize impact.
• Idempotency: Ensure your instrumentation logic doesn’t re-inject code if the source file is already instrumented (e.g., check for existing tracking calls before inserting new ones).

内容的提问来源于stack exchange，提问作者pajato0