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.

[da-x]

Yes, I also bumped in the past with the "Paths are workspace-relative rather crate-relative if a workspace exists regardless of where you run cargo build" issue.

The parsing of cargo metadata --no-deps --format-version 1 is clever. Originally the builtin 'Cbuild' has had this issue too, so it used a rather simplistic parsing method in the cargo#nearestWorkspaceCargo() function which does the work of walking up the directory tree to find the Cargo.toml that marks a workspace if one exists.

I wonder how ALE is handling this, because it seems to be handling workspaces correctly, and it uses neither methods.

[blueyed]

Re ALE: see https://github.com/w0rp/ale/blob/e0fe97e0a8e929bef9bd4d677c066968be70e914/ale_linters/rust/cargo.vim#L13-L21 and https://github.com/w0rp/ale/blob/e0fe97e0a8e929bef9bd4d677c066968be70e914/ale_linters/rust/cargo.vim#L50-L60.

They appear to also look for Cargo.toml.

[da-x]

Yes, however this code does not take into account whether there's an additional upper Cargo.toml which sets a workspace. Looking more into this, I figured out why it works - ALE looks into the JSON output for each warning and error, where it find absolute paths, and it appears to be matching them with the absolute paths of open buffers. So under these conditions, relative paths and current directory settings don't matter.

[blueyed]

ALE looks into the JSON output for each warning and error, where it find absolute paths

So there are absolute paths in there?
I've taken a closer look and there is src_path (we use file_name). This might be something newer.

However grepping for src_path in ALE's source didn't find something.
It appears to be only matched accidentally (it compares the tail): https://github.com/blueyed/ale/blob/f516cac47c244566db4f9b421974bdeb1310510f/autoload/ale/path.vim#L152

[da-x]

@dpc is this issue still relevant? Thanks

[dpc]

I've been working on my workspace enabled project for a while now, and I forgot the issue still exists, so I guess everything was fixed.