Paths printed relative to the Cargo.toml file interfere with M-x compile

[huonw]

If you're in a subdirectory of Cargo repository (e.g. src) and run cargo build, rustc is run from the directory with Cargo.toml, meaning all printed paths are relevative to that directory, not the one where cargo build was run.

Emac's M-x compile mode will "hyperlink" paths in error messages to allow jumping straight to the error (I'm sure other editors provide this functionality too), but it is taken relative to the folder of the buffer on which M-x compile was run (i.e. if you are editing .../src/lib.rs and run M-x compile cargo build then emacs assumes the diagnostics are relative to .../src). Hence, the automatic running of rustc in a different directory makes it harder to use that mode.

This would theoretically be fixed by running the rustc subprocess from the directory in which cargo is invoked.

[photex]

+10

I use projectile instead of M-x compile but the problem is the same since build errors lose helpful path information ("which mod.rs is this again?").

[vhbit]

Looks like not at issue anymore as compilation warnings/errors now contain full paths.

[alexcrichton]

Possibly solution: #694 (comment)

[flodiebold]

Note that the paths are still relative when compiling a crate at a non-standard location using a [[bin]] entry (and I assume the same goes for [[lib]]).