Provide a way to abort/suspend "cargo check"

[RalfJung]

In the rustc repository, "cargo check" can take a long time. During that time, any other x.py command is blocked because of the workspace lock. Sometimes, I am doing work where I do not want a full "cargo check" (e.g. when I am just editing a doc comment in libstd, or so). In that case, after doing the edit (which can take less than a minute), I now have to wait several minutes for "cargo check" to complete before I can run doctests (which doesn't need a full "check" of the entire compiler). That is enough friction that I end up using a different editor for this job just to avoid the automatic "cargo check".

Is there a way to temporarily (until I close this session, or so) disable "cargo check" in RA? I usually want "check" for the rustc workspace, so a workspace setting doesn't entirely fit here. Just sometimes I want to disable this until I close this workspace again.

[Veetaha]

This is definitely possible once we move to fully lsp-compatible progress reports for cargo check runs.
Related PRs: #4407
I might tackle this just once I have time, but everyone should feel free to take over

[kiljacken]

For now, a workaround is to save a file again without changing anything. This should cancel the check and yield the lock to the operation you've got waiting in your terminal.

[RalfJung]

That doesn't help with x.py unfortunately which performs many operations and often releases and re-acquires the lock.

I sometimes even get strange errors about not finding particular crates in the sysroot or so when my x.py and RA's check overlap -- re-running the x.py command fixes those.

[RalfJung]

For working on libstd I actually switched back to using another editor as vscode keeps rechecking all of rustc after each save, which is rather excessive.

[kiljacken]

You can always disable the flycheck/check-on-save functionality and manually invoke x.py as a vscode runnable.

[RalfJung]

Ah good point, I didn't realize there is a way to disable it.

I never used "vscode runnables", will have to look into this. Thanks!
(Searching for "vscode runnable" doesn't show anything useful though that I can see?)

[Veetaha]

{
    "rust-analyzer.checkOnSave.enable": false,
}

[kiljacken]

@RalfJung Ah sorry, that's because they're called "Tasks" and not runnables.

[kiljacken]

Something like:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "x.py",
            "type": "shell",
            "command": "./x.py",
            "problemMatcher": ["$rustc"]
        }
    ]
}

In tasks.json should be a starting point, I'm not able to check it right now though.

[RalfJung]

I have configured my tasks.json as follows:

		{
			"type": "shell",
			"command": "./x.py check --json-output",
			"problemMatcher": [
				"$rustc"
			],
			"label": "rustc full check"
		},

However, this behaves very differently from the normal "check" task. it opens a terminal to show the output with all the glorious JSON, and more important it does not actually interpret the JSON to highlight the errors in the code -- making it basically useless.

Is there a way to tell it to parse the JSON the way it normally would?

[Zapeth]

I recently got rust-analyzer working in Sublime Text editor and now encountered the same issue.

rust-analyzer.checkOnSave.enable=false isn't a solution for me because there is no way to execute a check operation operation otherwise (that I know of) and I don't think the tasks.json suggestion is applicable to non-vscode editors.

I'm not really familiar with the technical details of LSP, but if its possible I'd suggest a different approach where cargo check isn't executed on every save but rather only with an explicit command from the client. (I've been told workspace/executeCommand might be suitable for that?)

That way a key mapping could be bound to that command on the client and specifically executed by the user whenever desired/required.

[SomeoneToIgnore]

I'm not sure how good LSP is supported in Sublime Text 3, but there's a custom command in rust-analyzer, experimental/runnables

that allows running a "clever" cargo check:

it's supported in VSCode part of rust-analyzer and there might be a way to support it in Sublime?

[Zapeth]

Their docs list an LSP implementation status, but I'm not seeing anything experimental there so I'm assuming that its not supported.

However there is also more info regarding executing server commands.

Other than that these are the possible server-specific settings that can be configured in the plugin (any of rust-analyzer's settings can be set in settings):

// Sent to server once using workspace/didChangeConfiguration notification
"settings": { },

// Sent once to server in initialize request
"initializationOptions": { },

// Disable providers if so desired
"disabled_capabilities": { },

// Extra variables to override/add to language server's environment.
"env": { },

PS: I'm actually using ST4, as far as I know the last LSP plugin version for ST3 is relatively old and not being updated anymore (unfortunately ST4 currently also requires a license).

[RalfJung]

that allows running a "clever" cargo check:

Sadly that's not enough even inside vscode when one has set rust-analyzer.checkOnSave.overrideCommand. So this does not resolve my original issue I'm afraid. What would be best is if the exact thing that RA does "on save" automatically by default, could instead be triggered on-demand.

[RalfJung]

It looks like even hitting Ctrl-S will not abort the existing run to start a new one? At least, I am experiencing extremely high latency (>30s) between hitting Ctrl-S and RA starting a new check run (removing the old diagnostics and starting to add new one) when there is already a check run ongoing (I am in the middle of a big refactoring, so there is hundreds of diagnostics).