Fix logic for rust-analyzer.checkOnSave.features setting inheritance #4542
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem addressed by this PR
The rust-analyzer inherits the setting of
rust-analyzer.checkOnSave.features
fromrust-analyzer.cargo.features
by default, but the elisp code here was incorrectly defaulting the former to the empty list, regardless of the value of the latter. The effect was thatrust-analyzer.cargo.features
disabled warnings about "inactive code", without actually turning on type checking of that code!Besides fixing the bug, by distinguishing between "unset" (
null
in the rust-analyzer docs) and "set to the empty list" ([]
in the rust-analyzer docs), this PR also improves the docs, by mentioning the documented rust-analyzer settings that correspond to the Elisp variables here, which should help with discoverability of these settings (I had a hard time finding them).Example of the bug
Create a simple Rust project with a
Cargo.toml
like this:And a
src/main.rs
like this:If you open
main.rs
in Emacs withrust-analyzer
enabled, you will see that thatfoo
function definition and usage are inactive, because the"foo"
feature is not enabled:However, if you enable the
"foo"
feature in lsp by setting thelsp-rust-features
variable withM-: (setq lsp-rust-features ["foo"]) RET M-x lsp-restart-workspace RET
then you will see that the
foo
function definition and usage are no longermarked as inactive, but the type error is not highlighted:
After the fix in this PR, you instead see the type error highlighted:
The old behavior can be recovered by setting
lsp-rust-analyzer-checkonsave-features
to[]
, but that's no longer the default.