hover, symbols, definition return null or error on Windows due to path handling bug

[steveking-gh]

Environment

• OS: Windows 11
• rust-analyzer-mcp version: v0.2.0
• rust-analyzer version: installed via rustup component add rust-analyzer

Summary

On Windows, rust_analyzer_hover, rust_analyzer_symbols, and rust_analyzer_definition are non-functional. The root cause is that the server does not convert Windows paths to file:// URIs for LSP requests, nor strip file:// URIs back to plain paths for file I/O. Both conversions work trivially on Linux/Mac but require explicit handling on Windows.

rust_analyzer_set_workspace and rust_analyzer_diagnostics work correctly.

Reproduction

Using the MCP Inspector (npx @modelcontextprotocol/inspector rust-analyzer-mcp.exe):

1. Call rust_analyzer_set_workspace with C:\path\to\project → succeeds
2. Call rust_analyzer_hover with the following path formats:

Path format	Result
C:\Users\...\file.rs (Windows path)	Returns null silently
\?\C:\Users\...\file.rs (UNC path)	Server notification: LSP error: {"code":-32603,"message":"url is not a file"}
file:///C:/Users/.../file.rs (file URI)	MCP error -1: Failed to read file: The filename, directory name, or volume label syntax is incorrect. (os error 123)

Analysis

The server has two internal operations that both fail on Windows:

1. LSP request — expects a file:/// URI with forward slashes. Receiving a raw Windows path causes a silent null or LSP error.
2. File read — expects a plain Windows path. Receiving a file:/// URI causes OS error 123 because the URI is passed literally to the Windows filesystem API.

On Linux/Mac, file:///home/user/foo.rs ↔ /home/user/foo.rs is trivial. On Windows, file:///C:/Users/.../foo.rs ↔ C:\Users\...\foo.rs requires explicit conversion that is currently missing.

Expected behaviour

rust_analyzer_hover (and other position-based tools) should accept a standard Windows path and work correctly, matching the behaviour of rust_analyzer_diagnostics.