project: Use runnable kind to disambiguate between cargo and shell commands#54011

sunshowers · 2026-04-15T21:01:07Z

Found this bug while investigating why configuring nextest based on the instructions at rust-lang/rust-analyzer#21137 (comment) wasn't working within Zed.

Previously, we'd use serde(untagged), preferring cargo over shell commands. The problem is that every instance of a shell command is a valid instance of a cargo command. For example, the shell command:

{
    "label": "test my_test",
    "kind": "shell",
    "args": {
        "environment": {"RUSTC_TOOLCHAIN": "/path/to/toolchain"},
        "cwd": "/project",
        "program": "cargo",
        "args": ["nextest", "run", "--package", "my-crate", "--lib", "--", "my_test", "--exact", "--include-ignored"]
    }
}

would end up getting deserialized as a Cargo command, silently dropping program and args.

With this fix, we now use the provided kind as a tag. We do have to introduce a #[serde(flatten)] unfortunately, which has a few side effects due to internal buffering, but #[serde(untagged)] also does internal buffering so this doesn't make things worse.

I've manually tested this by configuring:

{
    "lsp": {
        "rust-analyzer": {
            "initialization_options": {
                "runnables": {
                    "test": {
                        "overrideCommand": [
                            "cargo",
                            "nextest",
                            "run",
                            "--package",
                            "${package}",
                            "${target_arg}",
                            "${target}",
                            "--",
                            "${test_name}",
                            "${exact}",
                            "${include_ignored}"
                        ]
                    }
                }
            }
        }
    }
}

and ensuring that nextest is correctly invoked.

Self-Review Checklist:

I've reviewed my own diff for quality, security, and reliability
Unsafe blocks (if any) have justifying comments
The content is consistent with the UI/UX checklist
Tests cover the new/changed behavior
Performance impact has been considered and is acceptable

Release Notes:

Fixed deserialization of rust-analyzer shell runnables.

cla-bot · 2026-04-15T21:01:10Z

We require contributors to sign our Contributor License Agreement, and we don't have @sunshowers on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

sunshowers · 2026-04-15T21:01:39Z

@cla-bot check

cla-bot · 2026-04-15T21:01:45Z

The cla-bot has been summoned, and re-checked this pull request!

zed-industries-bot · 2026-04-19T15:27:47Z

	Messages
📖	This PR includes links to the following GitHub Issues: #rust-lang/rust-analyzer#21137 If this PR aims to close an issue, please include a `Closes #ISSUE` line at the top of the PR body.

Generated by 🚫 dangerJS against 8d60f29

SomeoneToIgnore

Thank you for digging into this.

I guess then

zed/crates/project/src/lsp_store/lsp_ext_command.rs

Lines 503 to 504 in 5a589c4

    
           // https://rust-analyzer.github.io/book/contributing/lsp-extensions.html#runnables 
        
           // Taken from https://github.com/rust-lang/rust-analyzer/blob/a73a37a757a58b43a796d3eb86a1f7dfd0036659/crates/rust-analyzer/src/lsp/ext.rs#L425-L489

deserves some update/rewrite, can you do that?

I think CI fails will go away with a rebase and are not related.

…mmands Found this bug while investigating why configuring nextest based on the instructions at rust-lang/rust-analyzer#21137 (comment) wasn't working within Zed. Previously, we'd use `serde(untagged)`, preferring cargo over shell commands. The problem is that every instance of a shell command is a valid instance of a cargo command. For example, the shell command: ```json { "label": "test my_test", "kind": "shell", "args": { "environment": {"RUSTC_TOOLCHAIN": "/path/to/toolchain"}, "cwd": "/project", "program": "cargo", "args": ["nextest", "run", "--package", "my-crate", "--lib", "--", "my_test", "--exact", "--include-ignored"] } } ``` would end up getting deserialized as a Cargo command, silently dropping `program` and `args`. With this fix, we now use the provided `kind` as a tag. We do have to introduce a `#[serde(flatten)]` unfortunately, which has a few side effects due to internal buffering, but `#[serde(untagged)]` also does internal buffering so this doesn't make things worse.

sunshowers · 2026-04-26T20:35:29Z

Thanks @SomeoneToIgnore. I've rebased this on top of main and added a commit with an expanded comment on top. (Happy to squash this in if desired as well.)

To be honest I'd consider r-a to not be quite correct here, though I think it only does serializing so it doesn't get hit by this.

SomeoneToIgnore

Thank you!
No need to squash, we do that in the end anyway.

Fully agree with you that r-a has to get this fix ideally.

Veykril · 2026-04-27T09:52:56Z

To be honest I'd consider r-a to not be quite correct here, though I think it only does serializing so it doesn't get hit by this.

Curious to hear what the issue is on the r-a side (in your opinion). Note I haven't checked this PR yet to detail yet to catch up with this.

Veykril · 2026-04-27T10:00:00Z

Ah, the fact that we have the enums defined as untagged despite clearly having a tag field I suppose?

sunshowers · 2026-04-29T17:07:04Z

Ah, the fact that we have the enums defined as untagged despite clearly having a tag field I suppose?

Yeah, exactly -- I think the functional change in this PR can be directly transferred over to r-a. Do you want to do that or should I?

Veykril · 2026-04-30T12:46:53Z

If you could do that I'd really appreciate it, sounds like a reasonable change

sunshowers · 2026-05-06T05:55:33Z

If you could do that I'd really appreciate it, sounds like a reasonable change

Did this at rust-lang/rust-analyzer#22295.

Found this bug while investigating why configuring nextest based on the instructions at rust-lang#21137 (comment) wasn't working within Zed. Previously, we'd use `serde(untagged)`, preferring cargo over shell commands. The problem is that every instance of a shell command is a valid instance of a cargo command. For example, the shell command: ```json { "label": "test my_test", "kind": "shell", "args": { "environment": {"RUSTC_TOOLCHAIN": "/path/to/toolchain"}, "cwd": "/project", "program": "cargo", "args": ["nextest", "run", "--package", "my-crate", "--lib", "--", "my_test", "--exact", "--include-ignored"] } } ``` would end up getting deserialized as a Cargo command, silently dropping `program` and `args`. With this fix, we now use the provided `kind` as a tag. We do have to introduce a `#[serde(flatten)]` unfortunately, which has a few side effects due to internal buffering, but `#[serde(untagged)]` also does internal buffering so this doesn't make things worse. See zed-industries/zed#54011 for the original fix to Zed.

…mmands (zed-industries#54011) Found this bug while investigating why configuring nextest based on the instructions at rust-lang/rust-analyzer#21137 (comment) wasn't working within Zed. Previously, we'd use `serde(untagged)`, preferring cargo over shell commands. The problem is that every instance of a shell command is a valid instance of a cargo command. For example, the shell command: ```json { "label": "test my_test", "kind": "shell", "args": { "environment": {"RUSTC_TOOLCHAIN": "/path/to/toolchain"}, "cwd": "/project", "program": "cargo", "args": ["nextest", "run", "--package", "my-crate", "--lib", "--", "my_test", "--exact", "--include-ignored"] } } ``` would end up getting deserialized as a Cargo command, silently dropping `program` and `args`. With this fix, we now use the provided `kind` as a tag. We do have to introduce a `#[serde(flatten)]` unfortunately, which has a few side effects due to internal buffering, but `#[serde(untagged)]` also does internal buffering so this doesn't make things worse. I've manually tested this by configuring: ```json { "lsp": { "rust-analyzer": { "initialization_options": { "runnables": { "test": { "overrideCommand": [ "cargo", "nextest", "run", "--package", "${package}", "${target_arg}", "${target}", "--", "${test_name}", "${exact}", "${include_ignored}" ] } } } } } } ``` and ensuring that nextest is correctly invoked. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed deserialization of rust-analyzer shell runnables. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev>

Found this bug while investigating why configuring nextest based on the instructions at rust-lang#21137 (comment) wasn't working within Zed. Previously, we'd use `serde(untagged)`, preferring cargo over shell commands. The problem is that every instance of a shell command is a valid instance of a cargo command. For example, the shell command: ```json { "label": "test my_test", "kind": "shell", "args": { "environment": {"RUSTC_TOOLCHAIN": "/path/to/toolchain"}, "cwd": "/project", "program": "cargo", "args": ["nextest", "run", "--package", "my-crate", "--lib", "--", "my_test", "--exact", "--include-ignored"] } } ``` would end up getting deserialized as a Cargo command, silently dropping `program` and `args`. With this fix, we now use the provided `kind` as a tag. We do have to introduce a `#[serde(flatten)]` unfortunately, which has a few side effects due to internal buffering, but `#[serde(untagged)]` also does internal buffering so this doesn't make things worse. See zed-industries/zed#54011 for the original fix to Zed.

zed-codeowner-coordinator Bot requested review from a team, cameron1024, cole-miller and eholk and removed request for a team April 15, 2026 21:01

zed-community-bot Bot added the first contribution the author's first pull request to Zed. NOTE: the label application is automated via github actions label Apr 15, 2026

zed-codeowner-coordinator Bot assigned cole-miller Apr 15, 2026

cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Apr 15, 2026

sunshowers mentioned this pull request Apr 15, 2026

Add nextest support to Run Test and Run Tests posit-dev/ark#1155

Merged

SomeoneToIgnore self-assigned this Apr 19, 2026

SomeoneToIgnore approved these changes Apr 20, 2026

View reviewed changes

sunshowers added 2 commits April 26, 2026 13:33

more discussion in comment

d44c2aa

sunshowers force-pushed the runnable-kind branch from f97db6b to d44c2aa Compare April 26, 2026 20:33

SomeoneToIgnore approved these changes Apr 27, 2026

View reviewed changes

SomeoneToIgnore enabled auto-merge April 27, 2026 06:45

Merge branch 'main' into runnable-kind

8d60f29

Veykril self-assigned this Apr 27, 2026

SomeoneToIgnore added this pull request to the merge queue Apr 27, 2026

Merged via the queue into zed-industries:main with commit 47fb164 Apr 27, 2026
31 checks passed

sunshowers deleted the runnable-kind branch April 27, 2026 15:27

sunshowers mentioned this pull request May 6, 2026

Use runnable kind to disambiguate between cargo and shell commands rust-lang/rust-analyzer#22295

Open

	// https://rust-analyzer.github.io/book/contributing/lsp-extensions.html#runnables
	// Taken from https://github.com/rust-lang/rust-analyzer/blob/a73a37a757a58b43a796d3eb86a1f7dfd0036659/crates/rust-analyzer/src/lsp/ext.rs#L425-L489

Uh oh!

Conversation

sunshowers commented Apr 15, 2026

Uh oh!

cla-bot Bot commented Apr 15, 2026

Uh oh!

sunshowers commented Apr 15, 2026

Uh oh!

cla-bot Bot commented Apr 15, 2026

Uh oh!

zed-industries-bot commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Uh oh!

sunshowers commented Apr 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Veykril commented Apr 27, 2026

Uh oh!

Veykril commented Apr 27, 2026

Uh oh!

sunshowers commented Apr 29, 2026

Uh oh!

Veykril commented Apr 30, 2026

Uh oh!

sunshowers commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

zed-industries-bot commented Apr 19, 2026 •

edited

Loading

sunshowers commented Apr 26, 2026 •

edited

Loading