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

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:

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.

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 :)

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.

Solution posted in comments.

@matklad

@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.

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.

@mvanthoor

@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.

Wrong repo linked?

@jcdickinson

@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.

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.

Merge #4096

I can confirm: rolling back to RA v0.3.1885 makes it work again. I deleted my task and ran "Configure Default Task", and it produced this, which works:

{
	"tasks": [
		{
			"type": "cargo",
			"command": "build",
			"problemMatcher": [
				"$rustc"
			],
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"label": "rust: cargo build"
		}
	]
}

all my cargo tasks recently failing, I also confirm rollback to RA v0.3.1885 works

Does anybody know the root cause of this issue? Is it a bug or tasks.json should be updated to a new structure? Still have this issue on the latest v0.3.1906 with the following task:

{
	"label": "check",
	"type": "cargo",
	"command": "check",
	"problemMatcher": [
		"$rustc"
	],
	"group": {
		"kind": "build",
		"isDefault": true
	},
	"dependsOn": [
		"clear terminal"
	]
}

The same issue appears on v0.3.1896, but not on v0.3.1885.

I've got this happening as well, using rust-analyzer-0.3.1906-darwin-arm64. I've not tried rolling back to an older version yet, but it's been annoying me for a week or so now... :(

I'm not following rust-analyzer that closely, so I may be far off, but this has affected me as well. I'm hopeful that #16943 and #16949 cover the issue we're having, in which case it should hopefully be fixed in the next version due to #16970 (which just missed last Monday's release).

It now works as of 0.4.1907, so switch to prerelease until probably Monday, when it will be merged into stable

I can confirm that it works in the newest stable release. If everyone here confirms it also works for them, then we can close this issue.

Looks like it's working for me on the release version now too :)

"Working" from me too. Thank You for fixing it!

It seems to not be working again on v0.3.2003. However it did work on v0.3.1995 and it is also fixed on prerelease v0.4.2005.

Does anyone know when it will be fixed on stable? I don't want to use older versions or use unstable versions.

Next monday

Same here

Just to clarify, Monday the 24th?

yes

Navigation Menu

Repository navigation

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

Fixed

Problem description

Solution

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

mvanthoor commented on Apr 17, 2020

mvanthoor commented on Apr 21, 2020

Fixed

Problem description

Solution

mvanthoor commented on Apr 21, 2020

jcdickinson commented on Apr 22, 2020

mvanthoor commented on Apr 22, 2020

jcdickinson commented on Apr 22, 2020

bjorn3 commented on Apr 22, 2020

mvanthoor commented on Apr 22, 2020

matklad commented on Apr 22, 2020

16 remaining items

pkoevesdi commented on Mar 28, 2024

va1ha11a commented on Mar 31, 2024

mhnap commented on Apr 4, 2024

sazzer commented on Apr 4, 2024

patowen commented on Apr 5, 2024

coolCucumber-cat commented on Apr 5, 2024

coolCucumber-cat commented on Apr 10, 2024

sazzer commented on Apr 10, 2024

pkoevesdi commented on Apr 10, 2024

coolCucumber-cat commented on Jun 20, 2024

Veykril commented on Jun 20, 2024

yorickdewid commented on Jun 20, 2024

coolCucumber-cat commented on Jun 20, 2024

Veykril commented on Jun 20, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions