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?