LSP `CodeActionContext.only`: Rust-Analyzer checks still run (synchronously), not filtered out

[seritools]

rust-analyzer version: rust-analyzer version: 0.4.2604-standalone (fa19df2d0e 2025-09-04) [c:\Users\seri\.vscode-insiders\extensions\rust-lang.rust-analyzer-0.4.2604-win32-x64\server\rust-analyzer.exe]

rustc version: rustc 1.91.0-nightly (af00ff2ce 2025-09-04)

editor or extension:

Version: 1.104.0-insider (user setup)
Commit: 06acd067cb9621b055d9701324477cf75fa0e242
Date: 2025-09-05T09:02:10.455Z
Electron: 37.3.1
ElectronBuildId: 12259562
Chromium: 138.0.7204.235
Node.js: 22.18.0
V8: 13.8.258.31-electron.0
OS: Windows_NT x64 10.0.26200

rust-analyzer v0.4.2604 (pre-release)

relevant settings:

Add the following to your vscode settings:

  "editor.codeActionsOnSave": {
    "source.somethingUnrelatedToRustAnalyzer": true
  },

In my real-life case it was

  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },

from the ESLint extension.

code snippet to reproduce:

Create an empty lib project and add this single line (likely you need to have x86_64 as default target, or change to target to it)

use core::arch::x86_64::*;

to a file blocks every manual save action (Ctrl+S), in that file, for 1-3 seconds on my system.

• It does not seem to affect autosave on window change ("files.autoSave": "onWindowChange"). In those cases it immediately saves and runs cargo fmt. I think that's a VSCode setting related to codeActionsOnSave though.
• Using VSCode's entension bisect I confirmed that no other extension causes this.

The LSP logs when any codeActionsOnSave are set start with textDocument/codeAction taking ~2.7s:

[Trace - 9:31:15 PM] Sending request 'textDocument/codeAction - (144)'.
Params: {
    "textDocument": {
        "uri": "file:///x%3A/rustprojs/sdfkkdfgh/src/lib.rs"
    },
    "range": {
        "start": {
            "line": 0,
            "character": 0
        },
        "end": {
            "line": 3,
            "character": 0
        }
    },
    "context": {
        "diagnostics": [],
        "only": [
            "source.somethingUnrelatedToRustAnalyzer"
        ],
        "triggerKind": 2
    }
}


[Trace - 9:31:18 PM] Received response 'textDocument/codeAction - (144)' in 2711ms.
Result: []


[Trace - 9:31:18 PM] Sending request 'textDocument/formatting - (145)'.
Params: {
    "textDocument": {
        "uri": "file:///x%3A/rustprojs/sdfkkdfgh/src/lib.rs"
    },
    "options": {
        "tabSize": 4,
        "insertSpaces": true,
        "trimTrailingWhitespace": true
    }
}


[Trace - 9:31:18 PM] Received response 'textDocument/formatting - (145)' in 49ms.
Result: [
    {
        "range": {
            "start": {
                "line": 2,
                "character": 0
            },
            "end": {
                "line": 3,
                "character": 0
            }
        },
        "newText": ""
    }
]

If I remove the unrelated codeActionsOnSave settings entry the 2.7s call is entirely gone:

[Trace - 9:26:59 PM] Sending request 'textDocument/formatting - (50)'.
Params: {
    "textDocument": {
        "uri": "file:///x%3A/rustprojs/sdfkkdfgh/src/lib.rs"
    },
    "options": {
        "tabSize": 4,
        "insertSpaces": true,
        "trimTrailingWhitespace": true
    }
}


[Trace - 9:26:59 PM] Received response 'textDocument/formatting - (50)' in 55ms.
Result: [
    {
        "range": {
            "start": {
                "line": 2,
                "character": 0
            },
            "end": {
                "line": 3,
                "character": 0
            }
        },
        "newText": ""
    }
]

---

I think what's happening is that r-a does not handle CodeActionContext.only (LSP reference) ideally, and runs its own checks synchronously, before allowing to save, even though only being set should mean that the call should be a no-op if only unrelated settings are set.

use core::arch::x86_64::*; might also be an edge case as it imports so many intrinsics functions?

[ChayimFriedman2]

rust-analyzer cannot know what code emits which code action, since they are registered dynamically. So it indeed does not respect this setting.

Furthermore, my understanding of the LSP reference is that it allows this behavior. Quoting:

Actions not of this kind are filtered out by the client before being shown. So servers can omit computing them.

It does not require servers to not compute them.

[seritools]

rust-analyzer cannot know what code emits which code action

But rust-analyzer knows which actions it itself supports right? If only only contains actions r-a does not handle, AFAICT it should become a no-op. It doesn't have to, but it will cause issues like this one, blocking for no reason.

So there are two separate issues: One is that it takes 2.7s in the first place; the other is that it spends these 2.7s in a blocking call where it is entirely wasted anyways.

It does not require servers to not compute them.

Right, that's why I wrote that the behavior is not ideal. The behavior is still technically correct, just extremely slow in this case.
only is provided so that servers can skip computing unnecessary things, because that's a reasonable behavior.

[ChayimFriedman2]

But rust-analyzer knows which actions it itself supports right?

Even that is not true, although we can probably make it true pretty easily by prefixing all r-a assists with rust-analyzer at the protocol layer.