Allow selecting targets instead of passing --all-targets

[darkwater]

When working with RTFM, rust-analyzer constantly complains it can't find crate for 'test', since there is no std available for this target architecture. cargo check is always called with -all-targets, but I would like to call it with just --bins for this project.

[japaric]

constantly complains it can't find crate for 'test'

You can work around this issue using the following .vscode/settings.json file (on the projects that need it):

{
    "rust-analyzer.checkOnSave.allTargets": false,
    "rust-analyzer.checkOnSave.extraArgs": [
        "--bins"
    ]
}

(that calls cargo check --bins on save, instead of cargo check --all-targets)

You can use other combinations like --bins --examples --lib to check src/lib.rs, src/main.rs, src/bin/*.rs and examples/*.rs.

Omit --lib if you don't have a src/lib.rs file.

Note that --bins will check both src/main.rs and src/bin/*.rs.

It would be nice if RA used the right cargo check invocation for no_std targets though.

[luojia65]

By .vscode/settings.json way it would be great, but I can't turn to the definitions of variables anymore. May need a more graceful way for cross compile targets.

[crawford]

I'm trying to follow this recommendation, but applying it to Emacs/eglot instead. I can't seem to get it to take effect though. I can see the following message is passed to rust-analyzer

{"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{"rust-analyzer":{"checkOnSave":{"allTargets":false,"extraArgs":"--bins"},"trace":{"server":"verbose"}}}}}

But when I strace rust-analyzer, I still see

execve("/nix/store/k5hvhivn0lqi25ynziayxl1nb8kd4s00-rust-1.59.0-2022-02-23-9d1b2106e/bin/cargo", ["cargo", "check", "--workspace", "--message-format=json", "--manifest-path", "/home/alex/poe/firmware/Cargo.toml", "--all-targets"], 0x5591b2ac1c50 /* 130 vars */) = 0

I must be missing something obvious. I'm new to a lot of these tools, so I'm still fuzzy on how exactly everything strings together. Any hints would be greatly appreciated.

EDIT: I was able to figure out my issue. My Emacs/eglot configuration was such that the client was returning nil in response to workspace/configuration and I didn't realize that rust-analyzer ignores the parameters sent with workspace/didChangeConfiguration.

[TLATER]

@crawford See joaotavora/eglot#845 - rust-analyzer is "quirky" in that it doesn't support configuration/didChange, which eglot normally uses to change lsp configuration.

For the moment you need to use a snippet like this, adapted to your settings of course:

  ;; Rust-analyzer is "quirky", and doesn't support updating its
  ;; configuration settings once it's running. This means that eglot
  ;; has to configure it *before* it runs, which it doesn't do by
  ;; default.
  ;;
  ;; See also https://rust-analyzer.github.io/manual.html#configuration
  (cl-defmethod eglot-initialization-options ((server eglot-lsp-server))
    (pcase (eglot--major-mode server)
      ('rust-mode '(:checkOnSave
                    (:command "clippy")))
      (_ (eglot--{}))))

Also note that, unlike all other lsp server implementations I've seen, rust-analyzer doesn't take a :rust-analyzer prefix there, which may be confusing. I don't know why this all is, but I figured it out after a good 5 hours of staring at logs. I'll add a section about rust-analyzer's quirkiness to the eglot readme in time (want to figure out what else is weird about it first), and maybe update the emacs config section here to add some notes for eglot as well. Meanwhile eglot is looking into making the initialization options configurable more conveniently: joaotavora/eglot#901

I'm sure there are good reasons for this quirkiness. I'm actually here to see if others have done this before, to check if there's wisdom to start from, but apparently I'm in novel terrain here. Shame, really, eglot is much nicer to use than lsp-mode and could use some more community mindshare.