rust tasks test current function command

[kzhui125]

Check for existing issues

• [X] Completed

Describe the feature

VSCode now:

cargo test --package package --lib -- tests::it_works --exact --show-output 

add --lib so there won't be many bin tests output.

add --exact --show-output

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[JosephTLyons]

Hey @kzhui125, are you suggesting for us to simply add these flags to our Rust task for running the current test? (Disregard the doubled text in the tooltip)

cc @osiewicz for opinions

[kzhui125]

@JosephTLyons I want to test current function from library crate and show `println` output.

But there are many tests running from binary crate.

Thanks,

[kzhui125]

I didn't notice the tooltip, just want a way to test only current function, thanks,

[MrHeer]

Is anyone dealing with this issue? If not, I can try to fix it.

[SomeoneToIgnore]

Throwing in some details to help anyone interested to implement this.

To start with the data description,

VSCode now:

it's not VSCode but rust-analyzer with all its Rust knowledge that is adding those prefixes. Neither Zed nor VSCode editors know about Rust semantics such as modules, tests, macros, etc., so they have to get it out of external tools, either r-a or cargo, or something else.

• --show-output is fine to add right now, no extra information is needed, but it will bloat the test output more, appending the stats to every crate

• --lib/--bin/--example/--test/--bench needs to be aware of Rust & cargo semantics (bin crates have default paths, and may be overridden in Cargo.toml), so need either cargo metadata or r-a data (partially based on cargo metadata too). Not sure if hardcoding any heuristics in Zed itself will do good here, but so far it seems that we're mainly interested in --lib and --bin ones, for starters.

• --exact would need to fully qualify a module.

Currently, Zed uses pkgid

https://github.com/zed-industries/zed/blob/ddb551c794345538dbef112c5bcc2ae99f27b07f/crates/languages/src/rust.rs#L452-L465

I'm not certain if that is ok to convert into a qualifier, but given that there's a way to declare a module with one name and a differently named file

mod inline {
    #[path = "other.rs"]
    mod inner;
}

I'm not certain that pkgid is safe to convert into a qualifier.

---

In rust-analyzer all the data is relatively trivial to add: https://github.com/rust-lang/rust-analyzer/blob/71a816a90facb6546a0a06010da17598e11812f7/crates/rust-analyzer/src/cargo_target_spec.rs#L30 as by the time any Rust tasks are added into VSCode, r-a had loaded the entire project contents into its memory and queries it.

Unfortunately, there's no API to explicitly answer Zed's needs, as VSCode tasks are added via the task API and command API (that is also exposed via lens, but hide all cargo runnable data inside a data: Any field which contents is not expected to be accessed by the editors, but rather sent back to the server when needed to resolve/run/etc.), both kinds are being added in the r-a VSCode plugin on the client side.

As a workaround for Rust, we can consider rust-analyzer's extension methods: https://github.com/rust-lang/rust-analyzer/blob/master/editors/code/src/lsp_ext.ts , Zed uses rust-analyzer/expandMacro from it already. Among those methods, there are capabilities to list tests, and https://github.com/rust-lang/rust-analyzer/blob/71a816a90facb6546a0a06010da17598e11812f7/editors/code/src/lsp_ext.ts#L223-L236 seems to contain all that we need.

Both cargo metadata and LSP ext requests are relatively slow operations (cargo metadata might block for a long time, e.g. due to downloading new crates first) and should never be called to determine Zed's runnable data when displaying them in the editor: instead, that should be called only when we're about to run the task after a click on the arrow/opening the modal.