"cargo task detection didn't contribute a task for the following configuration"

[mvanthoor]

Hi :) Maybe someone can help with this issue. I've been using / testing Rust Analyzer for 10 days or so without issues, but since yesterday, something is wrong.

I've received two updates in two days: VS Code updated to 1.44.1, and Rust Analyzer updated to 0.2.135. Since then, the following error pops up when trying to debug a program by pressing F5:

"cargo task detection didn't contribute a task for the following configuration"

When I view the output, it shows me the pre-launch task that runs "cargo build". When I remove this task, I get the error that the pre-launch task isn't found (obviously), and the dialog to create it from a template. This creates the exact same task as I've been using since switching to Rust Analyzer.

However, the build does work, and the debugging also works. It seems I'm getting an error even though nothing is wrong.

If I remove Rust Analyzer in VSCode 1.44.1 and re-install RLS (and its pre-launch build task, because they're not the same), the error goes away.

[mvanthoor]

Hi :)

I hope this information helps a little bit.

• Updated to Visual Studio Code 1.44.2 on 17-04-2020 (latest).
• Disabled every extension, restarted VSCode: problem still there.
• Switched to Nightly build for Rust Analyzer: problem still there.

As soon as I remove (or disable) Rust Analyzer and swtich back to RLS, the error message doesn't pop up. I do not get this message with other tasks either; only when trying to run "rust: cargo build" as a prelaunch task for debugging.

If you need me to test something somehow, I'll be happy to do so. I like this extension and server for the speed and better completion as compared to RLS :)

[mvanthoor]

Fixed

This issue can be closed; the problem is fixed.

Problem description

When having RLS installed and you want to build your program before debugging, you need a pre-launch task. RLS creates such a task, with the following name:

"rust: cargo build"

This will work.

When you then remove RLS and install Rust Analyzer, this task doesn't work, so you can remove it. After removing the task and then debugging, a prompt appears that "rust: cargo build" cannot be found. (Obviously; it was just removed.) You can recreate the task from that prompt. With Rust Analyzer installed, a new pre-launch task is then created, with the name:

"Rust: cargo build"

Difference: capital R. When you want to debug, you therefore still get the error that "rust: cargo build" can't be found. If you change the name to have a capital R to match the prelaunch task name, the error "There were task errors" appears, stating that "cargo task detection didn't contribute a task for the following configuration", for which this issue was opened.

Solution

• Keep the prelaunch task name with the capital R: "Rust: cargo build"
• If you have still have them, remove both versions from task.json. There should be NO task which somehow matches "Rust: cargo build" in task.json. Then the build and debug session works as expected. It seems that Rust Analyzer provides its own prelaunch task internally, and it doesn't have to exist in tasks.json.

[mvanthoor]

Solution posted in comments.

[jcdickinson]

@matklad please re-open this, or I can log a new issue if you prefer. While there is a workaround, the current behavior isn't consistent with RLS (or any other VSCode) plugin and build task customization is currently impossible. For example, I would like to use this configuration (as Code-LLDB+DWARF extension is vastly superior to the C++ extension for Rust debugging):

	{
		"type": "cargo",
		"command": "build",
		"args": [
			"--target",
			"x86_64-pc-windows-gnu"
		],
		"problemMatcher": [
			"$rustc"
		],
		"group": {
			"kind": "build",
			"isDefault": true
		},
		"label": "rust: cargo build"
	}

This configuration is ignored and an msvc binary is built. Ideally, customizing the build task for tests should also be possible - I could maintain a "build megaissue" if you'd like.

I've got some free time coming up, and have some open PRs, but I could look into fixing this after all of that.

[mvanthoor]

Because of the comment of jcdickinson above, I have reopened this issue. I'd like to try code-lld+dwarf myself; didn't know about it.

(I use the MS C++ extension with GDB, and manually installed pretty printers, on binaries compiled with thr gnu toolchain on windows. This works for most types, but not all of them.)

If this behavior is not consistent and my solution is a workaround, then something changed; either in VSCode, or in one of the last two releases of RA. I only need this workaround since a week or two.

[jcdickinson]

@mvanthoor: I'd like to try code-lld+dwarf myself; didn't know about it.

It's a bit off-topic for this issue, but this repo demonstrates how to use it right now. You'll need to look at "tasks.json", "launch.json" and steps 1, 2.ii from the readme.

The main difference is that the locals/variables window in VSCode is much more usable: variables usually have meaningful names (not always) and more often have live values. There are some minor and subjective improvements when it comes to stepping through code (especially where stdlib is concerned). Hope this helps.

[bjorn3]

Wrong repo linked?

[mvanthoor]

@jcdickinson Thanks, I'll have a look at it.

However, variables are fine now (with their normal names and live values), apart from some special types such as smart pointers. Maybe lldb is still better, after this issue is resolved.

[matklad]

I probably won't have time to look into this right now, but I want to link microsoft/language-server-protocol#944 which should be a better approach to the whole task thing than the current set of static tasks.