Crash with Deno LSP on Windows when searching project symbols

[bpollack]

Summary

When I open a Deno project, using the Deno LSP, and attempt to navigate to a symbol (i.e. <Space>S) on Windows, Helix crashes with the following error:

thread 'main' panicked at helix-term\src\commands\lsp.rs:184:44:
called `Result::unwrap()` on an `Err` value: ()

The stack trace with RUST_BACKTRACE set full doesn't yield any symbols (it's just memory addresses bottoming out at BaseThreadInitHunk)

Reproduction Steps

I tried this:

1. Set up a Deno project with Helix. You can use https://git.sr.ht/~bmp/hayom if you want one that's already set up
2. Open any file in the project
3. Hit <Space>S to open the workspace symbol picker
4. Helix will crash

Note that this does not happen on macOS or Linux, just Windows.

I'm using Deno 1.45.4 for this test.

Helix log

Backtrace:

thread 'main' panicked at helix-term\src\commands\lsp.rs:184:44:
called `Result::unwrap()` on an `Err` value: ()
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

(Running with RUST_BACKTRACE=full, as noted, just prints out memory addresses with no symbols.)

~/.cache/helix/helix.log

I can't fit the log here; it's over the length limit with the above repro steps due to the symbol dump getting in there. I'm happy to provide it on request.

Platform

Windows

Terminal Emulator

Windows Terminal

Installation Method

scoop

Helix Version

24.7

[the-mikedavis]

Can you try building from source? The function that crashed was changed in #9647 and shouldn't crash any more. Based on the backtrace I assume deno is sending an invalid or custom URI that we can't convert into a file path. (I believe there are other issues we've seen where deno does that.)

[bpollack]

On a very quick pass, building Helix fails because the tree-sitter grammars are failing to compile properly. I'll need to poke and see what's up. Do I have to use Rust 1.74? I'm wondering if this is a toolchain issue

[the-mikedavis]

You'll need at least Rust 1.74 and a C/C++ compiler. The tree-sitter grammars are written in C/C++ so the C/C++ compiler may be the issue

[bpollack]

Yeah, I'm completely failing to get them to build on either Windows box; they're dying with a pile of symbol errors. I haven't had time to figure out what's up there, but I will update this issue if I can sort that and then confirm the fix.