Checking doesn't work for workspace projects.
radupopescu opened this issue · comments
Hi there!
I have a Rust project organized as a workspace - in the root of the project, there are two other sub-crates which are part of the workspace.
When editing the main file of the root project (<PROJECT_ROOT>/src/main.rs) or even the library part of the root project ('<PROJECT_ROOT>/src/lib.rs`) there are no issues with flycheck.
When editing the contents of any of the sub-crates (i.e. <PROJECT_ROOT>/<SUBCRATE>/src/lib.rs) there is no checking happening.
I suspect that flycheck isn't aware of workspace projects. When checking my code from the command line, I usually have to specify the --all parameter to the check command to instruct it to recurse into sub-crates. For example:
$ cargo check --all --tests
I don't know how this is done with cargo rustc.
Here are some diagnostics/output from my computer:
Syntax checkers for buffer mod.rs in rust-mode:
rust-cargo
- may enable: yes
- predicate: t
- executable: Found at /Users/radu/.cargo/bin/cargo
- Cargo.toml: Found
- Crate type: lib
- Binary name: Not required
rust
- may enable: yes
- predicate: t
- executable: Found at /Users/radu/.cargo/bin/rustc
Flycheck Mode is enabled. Use C-u C-c ! x to enable disabled
checkers.
--------------------
Flycheck version: 32snapshot (package: 20180116.147)
Emacs version: 25.3.1
System: x86_64-apple-darwin13.4.0
Window system: nil
This is how I configure Flycheck in my Emacs' init.el:
;;; Rust ;;;
;;;;;;;;;;;;
(use-package racer
:init
(setq racer-cmd "~/.cargo/bin/racer")
:config
(use-package company-racer)
(use-package cargo)
(use-package flycheck-rust)
(add-hook 'rust-mode-hook 'cargo-minor-mode)
(add-hook 'rust-mode-hook #'racer-mode)
(add-hook 'rust-mode-hook
(lambda ()
(add-hook 'flycheck-mode-hook #'flycheck-rust-setup)))
(add-hook 'racer-mode-hook #'eldoc-mode)
(add-hook 'racer-mode-hook #'company-mode))
It would be really useful to have flycheck support in workspace projects.
Thanks for the great work on Flycheck, this is the first issue I've encountered for Rust, it works great otherwise!
Do you have some code with which to reproduce? A minimal example would be great. Here I have no issues checking code inside a subcrate of this project for instance.
Sure thing. Check out this minimal project. I'm seeing the same behaviour: flycheck works for fc-root/src/main.rs, but doesn't for fc-root/fc-sub/src/lib.rs.
I'm sorry to report that it works on my side :/
Opening fc-root/fc-sub/src/lib.rs, I can type gibberish and get a syntax error, or create an unused variable and get a warning.
If I open fc-root/src/main.rs, same thing.
However, if there is an error in fc-root/fc-sub/src/lib.rs, then you won't get any error feedback when editing fc-root/src/main.rs, because Flycheck is not project-aware. But note vice versa: editing the subcrate while the main binary of the root crate has an error is fine, because the subcrate does not depend on the root.
Other than that, what's your rustc version? 1.23?
It seems that it's the rust version that breaks things. I am on Rust nightly (with rustup default nightly). If I switch to stable, I can reproduce all the behaviour you listed in your reply.
Is it a known thing that nightly doesn't work with Flycheck, or is it a regression in the version I have installed (rustc 1.25.0-nightly (8ccab7eed 2018-01-31))?
It's a bit annoying, because I switched to nightly to be able to use rustfmt from Emacs...
Workspaces breaking on nightly is news to me. On the other hand, our testing infrastructure is a bit lacking, so I can't say for how long this has been broken. Luckily, we've got users who report bugs soon enough ;)
I've looked into this, and this stems from the fix to #1378 that was incomplete. For workspace projects, cargo reports paths relative to the workspace root, not relative to the nearest project. This is inconvenient, because it means we always have to find the topmost Cargo.toml. Or we can ask cargo metadata for the workspace root... don't know which would be faster in the end.
In any case, I'd rather have cargo spout out absolute file paths again (or at least relative to the nearest project...)
rust-lang/cargo#4788 is the culprit, rust-lang/cargo#4933 added workspace_root to cargo metadata, and rust-lang/cargo#4998 is still arguing that the change may be problematic.
I'll hop onto rust-lang/cargo#4998 to see if we can't get absolute paths in the JSON format.
@fmdkdd Thanks for looking into this and for the in-depth explanation! Indeed, it sounds that getting absolute paths would be easiest on you guys and also make any tools based on these values less brittle.
I tested cargo metadata on a stand-alone project (non-workspace), on nightly. The workspace_root data member is still present.
Does cargo return relative paths also in the case of non-workspace projects?
Does cargo return relative paths also in the case of non-workspace projects?
Yes it does, that was the cause of flycheck/flycheck#1378
Should be fixed by flycheck/flycheck#1422.
Thanks!