WIP: Add support for detecting tests in source files, and implement it for Rust

[mikayla-maki]

TODO:

• Wire up a new query
• Use this query to find tests in the current file range
• Render a play button in that location
• Spawn the test template from that play button when clicked

Release Notes:

• TODO

[osiewicz]

A question/food for thought: will all of the tests show up in a task modal?
On one hand I think that'll bloat the modal, but on the other it would be inconsistent to not include them.

[davidbarsky]

Hi! Sorry for butting in (asking since I'm a maintainer on rust-analyzer and I use Zed...), but would it be possible to use rust-analyzer's runnable functionality instead, by any chance?

(We'll be changing to extend support for non-Cargo build systems in rust-lang/rust-analyzer#16840, but we don't expect to change the custom LSP request beyond what's in that PR.)

[osiewicz]

Hey,
We did consider using an lsp extension for tasks (see #7108), but it does not solve test discoverability problem for language servers without these kinds of protocol extensions. In theory though we can consume VSC tasks just fine.

[davidbarsky]

Hey,

We did consider using an lsp extension for tasks (see #7108), but it does not solve test discoverability problem for language servers without these kinds of protocol extensions. In theory though we can consume VSC tasks just fine.

Thanks! I read through that, I appreciate you linking to your thinking on the matter! Obviously, y'all are the maintainers, but I'm curious as to how feasible it'd be to take a treesitter-based approach for all languages as a baseline and enhance specific languages (such as Rust) with LSP extensions. The benefit of LSP-based tasks would be more accurate task generation because rust-analyzer is able to see through macro expansions and whatnot.

From an implementation standpoint, I think there might be some complications around scaling this approach/figuring out how it interacts with Zed's extension API, but for rust-analyzer at least, I'd be happy to send PRs to Zed each time that request corresponding to runnables changes (the PR I linked to would be first change in 3-4 years, fwiw).

I don't expect much would change on the Zed side of things, since I think the task templates y'all have are sufficiently flexible. I think the integration boils down to mapping the right fields in the runnable response to the pre-existing task template in Zed.

[mikayla-maki]

but I'm curious as to how feasible it'd be to take a treesitter-based approach for all languages as a baseline and enhance specific languages (such as Rust) with LSP extensions.

That's where I'm thinking we'll end up :D We'd love support on maintaining experimental API protocols like this :) @davidbarsky

[davidbarsky]

but I'm curious as to how feasible it'd be to take a treesitter-based approach for all languages as a baseline and enhance specific languages (such as Rust) with LSP extensions.

That's where I'm thinking we'll end up :D We'd love support on maintaining experimental API protocols like this :) @davidbarsky

That's great to hear! I wasn't sure how open y'all would be to that, but I'm very happy you are! I'll keep my eyes peeled on opportunities for changes that make that possible.

[osiewicz]

Closing this in favor of #11195