Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix logic for rust-analyzer.checkOnSave.features setting inheritance #4542

Merged
merged 1 commit into from
Sep 14, 2024

Conversation

ntc2
Copy link
Contributor

@ntc2 ntc2 commented Sep 9, 2024

Problem addressed by this PR

The rust-analyzer inherits the setting of rust-analyzer.checkOnSave.features from rust-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 that rust-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:

[package]
name = "example"
version = "0.1.0"
edition = "2021"

[features]
foo = []

[dependencies]

And a src/main.rs like this:

fn main() {
    #[cfg(feature = "foo")]
    foo();
}

#[cfg(feature = "foo")]
fn foo() {
    // Type error:
    let x = 1 + "2";
    println!("{}", x);
}

If you open main.rs in Emacs with rust-analyzer enabled, you will see that that foo function definition and usage are inactive, because the "foo" feature is not enabled:

defaults

However, if you enable the "foo" feature in lsp by setting the lsp-rust-features variable with

M-: (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 longer
marked as inactive, but the type error is not highlighted:

before-fix

After the fix in this PR, you instead see the type error highlighted:

after-fix

The old behavior can be recovered by setting lsp-rust-analyzer-checkonsave-features to [], but that's no longer the default.

@jcs090218
Copy link
Member

nit:

lsp-rust.el:600:2: Warning: custom-declare-variable `lsp-rust-analyzer-checkonsave-features' docstring wider than 80 characters

The rust-analyzer inherits the setting of `rust-analyzer.checkOnSve.features`
from `rust-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 that `rust-analyzer.cargo.features` disabled warnings
about "inactive code", without actually turning on type checking of that code!
@ntc2
Copy link
Contributor Author

ntc2 commented Sep 10, 2024

nit:

lsp-rust.el:600:2: Warning: custom-declare-variable `lsp-rust-analyzer-checkonsave-features' docstring wider than 80 characters

Oops. I just reformatted the doc string and rewrote the commit.

Curious, how do you produce this error?

@jcs090218
Copy link
Member

Curious, how do you produce this error?

lsp-mode uses Eask to build and test. You can do:

# Clone this repo
$ git clone https://github.com/emacs-lsp/lsp-mode

# Navigate to project dir
$ cd lsp-mode

# Install dependencies
$ eask install-deps

# Compile to see warnings/errors (if any)
$ eask compile

Overall, LGTM! :)

@jcs090218 jcs090218 merged commit edec6f6 into emacs-lsp:master Sep 14, 2024
10 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client One or more of lsp-mode language clients documentation rust
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants