Cargo should print appropriate relative paths when being run from a non-root folder

[Manishearth]

Currently, if you run cargo commands from a place that is not the root (workspace root for workspace projects), it does (almost¹) the same thing as if you had run cargo <foo> -p packagename from the workspace root.

This means that the diagnostics also assume you are at the workspace root:

[10:17:15] मanishearth@manishearth-glaptop ~/dev/icu4x/components/calendar ^_^ 
$ carg<sup>1</sup>o check
   Compiling icu_calendar v0.3.0 (/home/manishearth/dev/icu4x/components/calendar)
warning: missing documentation for the crate
  --> components/calendar/src/lib.rs:5:1
   |
5  | / #![cfg_attr(not(any(test, feature = "std")), no_std)]
6  | |

It would be nice if cargo could tell rustc where it is being invoked from, so that rustc may print appropriate paths. A lot of IDEs and terminals have the ability to click on paths in compiler output to open files; and it's frustrating that this only works if you cargo build -p package from the workspace root.

¹ I believe there are some slight differences as to which dependencies get built when you call cargo build -p foo from the root vs a folder that depends on foo

See also

• Command line option to print full file paths #5450
• Error messages use relative paths differently if in a workspace #5895

Summary Notes

• unstable-Zroot-dir by weihanglo

Managed by @rustbot—see help for details

[ehuss]

Can you clarify, I don't think this is specific to workspaces? That is, if you go to the src directory and run cargo build, you get the same effect where the paths displayed are not relative to the current directory?

[Manishearth]

Yeah, you're right, this isn't actually related to workspaces

[Manishearth]

We could use -Zremap-cwd-prefix here: rust-lang/rust#87320

[danakj]

I'm not sure remap-cwd-prefix helps, but perhaps an example, to make sure I am understanding.

crate root: /home/foo/mycrate
current working dir: /home/foo/mycrate/somedir

What -Zremap-cwd-prefix=. would do is remap any paths in rustc of the form /home/foo/mycrate/somedir/blah to ./blah.

But it would not do anything with other paths rooted under /home/foo/mycrate. You would need to --remap-path-prefix=$CRATE_ROOT:$REL_PATH_FROM_CWD_TO_CRATE_ROOT to get what I think this is looking for.

[Manishearth]

Yeah it doesn't, i just realized: remap-cwd-prefix affects debuginfo, which is not good for build caching

remap-path-prefix has the same problem

[danakj]

Right. It's good for build caching if you're replacing something variable (an abs path) with something fixed (.) which is the point of it really. But for this scenario I think you don't want to touch the debuginfo, as you say.

[bjorn3]

It would be nice if cargo could tell rustc where it is being invoked from, so that rustc may print appropriate paths.

Say you do

$ cargo build -p crate1
$ cd crate1 && cargo build

Telling rustc where it is invoked from would require rustc to be run twice in this scenario. This is not a theoretical scenario as this exact thing will happen if you have the workspace open in your editor with cargo build running in the background at the workspace root and then from a terminal run cargo build in the directory of the specific crate you are working on.

[Manishearth]

Telling rustc where it is invoked from would require rustc to be run twice in this scenario

Why so? The flag is excluded from build caching.

[bjorn3]

But then the diagnostics would be outdated when you switch directory as cargo caches the old diagnostics.

[Manishearth]

hmmm, interesting point

that's only for successful builds, though. I wonder if there's something that can be done here

(Perhaps cargo should be operating on the json output for cached messages)