Error messages use relative paths differently if in a workspace

[jimblandy]

Error messages printed by rustc are relative to the path printed by cargo only when the crate is not part of a workspace. When the crate is a workspace member, rustc's messages are relative to the workspace directory. This makes it hard for programs like Emacs to find the file to which the error messages apply.

Here's the non-workspace case:

$ pwd
/home/jimb/play
$ cargo new str2
     Created binary (application) `str2` project
$ cd str2
$ echo bleah >> src/main.rs
$ cargo check
    Checking str2 v0.1.0 (file:///home/jimb/play/str2)                                                   
error: expected one of `!` or `::`, found `<eof>`
 --> src/main.rs:4:1
  |
4 | bleah
  | ^^^^^ expected one of `!` or `::` here

The path in the rustc error message, src/main.rs, is relative to the path given in the Checking... message, /home/jimb/play/str2.

But if we create a workspace, things are different:

$ pwd
/home/jimb/play
$ mkdir str
$ cd str
$ cat > Cargo.toml << EOF 
> [workspace]
> members = [ "member" ]
> EOF
$ cargo new member
     Created binary (application) `member` project
$ echo bleah >> member/src/main.rs
$ cargo check
    Checking member v0.1.0 (file:///home/jimb/play/str/member)                                           
error: expected one of `!` or `::`, found `<eof>`
 --> member/src/main.rs:4:1
  |
4 | bleah
  | ^^^^^ expected one of `!` or `::` here

In this case, rustc's error message cites member/src/main.rs, while cargo's output cites /home/jimb/play/str/member.

This behavior is consistent regardless of the directory in which one invokes cargo check, cargo build, or whatever.

See also

• Command line option to print full file paths #5450
• Cargo should print appropriate relative paths when being run from a non-root folder #9887

[ehuss]

The typical way to deal with this is to run cargo metadata and inspect the workspace_root value to determine the base path for all relative paths (regardless if it's in a workspace or not). I'm not sure what emacs package you are using, but the one I'm aware of does this (https://github.com/kwrooijen/cargo.el/blob/c995b42e2c0fc609d265286ce465d508d81b8a4d/cargo-process.el#L243-L251). I'm not terribly familiar with emacs, but maybe this is an issue with the package?

[dwijnand]

Another solution could be implementing #5450.

[jimblandy]

I talked with @alexcrichton this morning. He didn't see a problem with simply having cargo consistently run rustc from the top directory of the crate being compiled, instead of running it sometimes from the crate's top directory, and sometimes from the workspace. The only concern he raised was that the paths in the debug info are affected by the paths passed to rustc.

I am using cargo.el for other cases. But the basic Emacs tools ought to work, and it seems easy enough for cargo to give it what it needs.

[edit: the standard Emacs distribution includes a package compile.el, which is what people generally use for running compilations within Emacs. It has the usual jump-to-error and next-error commands. It parses lines like the 'Entering directory' and 'Leaving directory' lines that recursive makefiles produce, to track the base directory to which error message paths are relative. Since it's in the stock distribution, it's the tool most Emacs users are familiar with, and it supports many other compilers, it would be very nice for it to work with Rust too.]

[jimblandy]

Another solution could be implementing #5450.

Yes, that might be good too.