Unknown RLS configuration: crate_blacklist

[EFanZh]

My Visual Studio Code shows the warning after opening a Rust project:

Unknown RLS configuration: `crate_blacklist`

Currently, the version of stable RLS is 1.37.0, and I think it doesn’t support that configuration.

[bencooper222]

I have this issue too. The issue is that this is a default setting inside VSCode. We can override it to be null or some sort of array but a VSCode user cannot just make the setting not exist - if it's a default setting it has to be a value.

I'm not familiar with your codebase so I'm probably wrong about this but it seems like passing an invalid config to the extension shouldn't make it useless? As long as that's true, this extension seems vulnerable to stuff like this from vscode.

[kawadumax]

I have this issue too!

[Evolveye]

I can write more about it.
I have just created and opened cargo project

So that have to be extension default values mistake

[biuniun]

I am having the same issue.

[ronvoluted]

+1

[a4z]

I also have this issue since recently (the latest update?)
did not have it before

[jasonwilliams]

Checking in, have it also.

[karipov]

rustc 1.37.0 (eae3437df 2019-08-13) - same problem.

[dulinux]

Same here.

rustc 1.37.0 (eae3437df 2019-08-13)

[lhwcd]

I am having the same issue.

[kanekv]

I have same issue on nightly rustc 1.38.0-nightly (69656fa4c 2019-07-13)

[perlindgren]

I have this problem too (running arch linux with latest stable toolchan).

Is there a consequence to it? If so is there a workaround?

[uetchy]

rustup default nightly then rustup update fixes this issue. but another warning message popped out.

RLS configuration option `use_crate_blacklist` is deprecated: use `crate_blacklist` instead

[captain-yossarian]

@uetchy Same situation I have

[pscott]

@uetchy second that

[k06a]

Same for me

[LanceAdd]

me too

[LanceAdd]

Unknown RLS configuration: crate_blacklist
2019.9.19

[DM-Berger]

I'm getting this issue as well, on both MacOS and Linux.

For now, I have been silencing the warning by simply deleting the entries:

"rust.use_crate_blacklist": {
	"type": "boolean",
	"default": true,
	"description": "Don't index crates on the crate blacklist.",
	"scope": "resource",
	"deprecationMessage": "Use `rust.crate_blacklist` instead"
},
"rust.crate_blacklist": {
	"type": [
		"array",
		"null"
	],
	"default": [
		"cocoa",
		"gleam",
		"glium",
		"idna",
		"libc",
		"openssl",
		"rustc_serialize",
		"serde",
		"serde_json",
		"typenum",
		"unicode_normalization",
		"unicode_segmentation",
		"winapi"
	],
	"description": "Overrides the default list of packages for which analysis is skipped.\nAvailable since RLS 1.38",
	"scope": "resource"
},

in ~.vscode/extensions/rust-lang.rust-0.6.3/package.json.

This seems like a really bad fix, as uninstalling and installing the rls extension via the GUI does not seem to revert these changes to package.json, meaning the extension folder must be manually deleted and re-installed whenever this issue is updated.

However, it does kill the error message without having to switch to nightly, and everything else from the extension seems to continue working normally in the meantime without these entries.

[Xanewok]

I'm sorry for the confusion here - if anything it shows that we need to work better on on our configuration wrt syncing extension release lifecycle and the Rust toolchain trains.

Now we naively dump the configuration from the client side to the RLS, which obviously results in the 'unknown configuration' error since the configuration didn't exist before then.

One answer is to respond in the LSP initialization request with a list of supported configurations and then only send these manually by the client. The RLS would have to accept deprecated ones for a couple of releases though to allow time to transition to different configuration (like in this case).

Short-term solution would be to wait a couple of days for the stable 1.38 release and prune the deprecated config entirely for now.

[JKAnderson409]

I was having this issue with the 1.39.0-nightly version via rustup. The error message was more informative than with the stable toolchain (of which 1.37 is still the most recent available) but it is the extension that needs updating. Removing just the "rust.use_crate_blacklist" option from "~/.vscode/extensions/rust-lang.rust-0.6.3/package.json" silenced this non-error for me.

[jice-nospam]

Thanks for the hint. I had to remove both rust.use_crate_blacklist and rust.crate_blacklist to finally silence it.

[cseder]

I've been plagued with this error popping up in VS Codium as well, what I did to silence it was to remove this option in "~/.vscode/extensions/rust-lang.rust-0.6.3/package.json":

"rust.use_crate_blacklist": {
	"type": "boolean",
	"default": true,
	"description": "Don't index crates on the crate blacklist.",
	"scope": "resource",
	"deprecationMessage": "Use `rust.crate_blacklist` instead"
},

AND adding this to the default VS Codium / VS Code settings.json file:

"rust.crate_blacklist": null

Now it seems to finally shut up about it...

[Xanewok]

Please update the extension to the 0.7 version, the Rust toolchain to 1.38 and let me know if the problem still persists, thanks!

[ghost]

It's working good for me after the update 👍

[binarytom]

update is working good.

[snawaz]

I have this issue too. The issue is that this is a default setting inside VSCode. We can override it to be null or some sort of array but a VSCode user cannot just make the setting not exist - if it's a default setting it has to be a value.

It has nothing to do with VSCode. I'm using nvim, and I'm getting the same:

The problem is with the RLS.

[CaribouJohn]

I was having this issue too in code-insiders v1.48 I set the user setting to