Neomake - workspaces are broken

[dpc]

I'm opening this issue just to get some visibility of people that are both Rust user and VimL-versed.

neomake/neomake#1916

Let's say you have project a with a/b subcrate.

If you cd a/b and vim, neomake stops working well, because rustc still displays error paths as b/src/lib.rs (relative to workspace root) while neomake/Vim would like them to be relative to current dir, so just src/lib/rs.

All it takes to fix (I think) is fixing the path somewhere here: https://github.com/neomake/neomake/blob/master/autoload/neomake/makers/ft/rust.vim#L136 by stripping the prefix.

But it's currently beyond me, how to do it right, and I don't have time to dedicate to figure it out.

Please, someone take a look. :)

[dpc]

The same problem happens eg. in VSCode BTW.

[blueyed]

As for Neomake, it should probably cd to the project root?
Currently it cds to the parent dir of the buffer (https://github.com/neomake/neomake/blob/28f6991f3546195e764052d5e1c731432ac8f706/autoload/neomake/makers/ft/rust.vim#L28), which also means that it should not make a difference if you cd yourself (this is for the cargo maker, but not rustc for example!). Please consider filing an issue in Neomake as a followup if e.g. this is not working with rustc for you, but with cargo.

[dpc]

@blueyed I'd like to help, but I am so confused that I don't know how to answer any part of your question.

As for Neomake, it should probably cd to the project root?

The problem is that with Rust workspaces the is "root workspace dir" and bunch of "root crate dirs". inside it. When I use rust.vim + neomake in a typical project that has one crate (and thus workspace root == crate root) I can cd anywhere in the project, and :ll jumps to error just fine.

When I start a workspace things work only if the current dir is the workspace root.

Not sure if it's any help.

[blueyed]

Does it also affect cargo, or only rustc? (the former does cd in Neomake, the latter does not)
You can check :echom getloclist(0) to see the parsed location list.
It looks like an issue in Neomake's makers, which need to be adjusted probably, but we need to figure out which ones are affected.
I think cd'ing to %:p:h is not the best probably (i.e. it might not match the maker's output).
Would be good to get this analyzed per maker (i.e. use :Neomake rustc, and/or :Neomake cargo alone, but you appear to be only using cargo, aren't you?).

[dpc]

Does it also affect cargo, or only rustc

My naive understanding is that rustc maker would work only for standalone .rs files, which is very, very rarely how people do things in Rust. I've just tried and the error suggests that the whole thing doesn't compile since it's not aware that the file is a part of a bigger rust crate. In that case, there can be no workspaces (because they are cargo concept, AFAIK). So I guess rustc can be ignored.

If it is of any help, there is a topic about how to detect workspace dir: rust-lang/cargo#4933 . I'm also happy to assist as a guinea pig.

It looks like it's just a matter of calling cargo metadata and looking up:

"workspace_root":"/home/dpc/lab/crev"

key in the JSON output.

[blueyed]

@dpc
Isn't the workspace root the same as where Cargo.toml is? (this is what Neomake's cargo maker uses (bonidjukic/pinax-stripe@80e618e))

We could certainly change this to use the metadata, although that's an extra call etc (but looking for the Cargo.toml is similar already).
It would be better if cargo had an option to use absolute paths, or would make them relative to cwd after all. Apparently it was changed in rust-lang/cargo#4788.

[dpc]

@blueyed

> find . | grep Cargo
./Cargo.lock
./crev-data/Cargo.toml
./crev-lib/Cargo.toml
./crev-bin/Cargo.toml
./crev-common/Cargo.toml
./Cargo.toml

Both crates and workspaces itself have a Cargo.toml. cargo metadata is a static, Rust binary, so it should be as fast any other system command being called.

[blueyed]

@dpc
I see. Giving this a try.
I assume cargo metadata --no-deps --format-version 1 should be run in the buffers directory for best effects?

[dpc]

@blueyed I don't know the asnwer, but I expect cargo metadata should give the same results across the whole workspace.