Using --manifest-path, the filenames in error messages are relative to the manifest, not the current working directory

[RalfJung]

Problem

When using --manifest-path, the filenames in error messages are relative to the manifest given, not the directory cargo is invoked from.

Steps

1. For example in Miri, introduce a build failure in cargo-miri/src/main.rs.
2. Run cargo check --manifest-path cargo-miri/Cargo.toml
3. Notice the error refers to src/main.rs:21:17

Possible Solution(s)

Cargo could instruct rustc to print the paths relative to a given directory, or it could adjust the paths itself.

Notes

This also affects the rustc repo, where we have 3 workspaces currently (the main one, bootstrap, and codegen_cranelift). Errors in codegen_cranelift show paths that are quite hard to interpret since they are relative to src/compiler/rustc_codegen_cranelift, which is hard to users to even realize.

Version

No response

[weihanglo]

Some other issues around relative path in error messages:

• Command line option to print full file paths #5450
• Error messages use relative paths differently if in a workspace #5895
• Cargo with explicit manifest path has wrong warnings/errors paths #8506
• Cargo should print appropriate relative paths when being run from a non-root folder #9887
• Add an option to use relative paths or full paths when building projects #11043

Basically, this is by design that always be relative to the workspace root. Most projects have a workspace at the root of the repository, and most IDE also depends on workspace when building Cargo projects.

Maybe we do need a -Zdiagnose-with-full-path, so that either IDE or anyone's specialized tool can take advantage of absolute path without ambiguity.

In the meanwhile, could you try if it helps with --remap-path-prefix or -Zremap-cwd-prefix? For example,

RUSTFLAGS='--remap-path-prefix cargo-miri=' cargo check --manifest-path cargo-miri/Cargo.toml

Not ideal I know. Sorry about that :(

[RalfJung]

Basically, this is by design that always be relative to the workspace root. Most projects have a workspace at the root of the repository, and most IDE also depends on workspace when building Cargo projects.

I am not talking about workspace projects though. I am talking about using --manifest-path to build a different workspace.

If you read the discussion at rust-lang/rust-analyzer#10793 and the other backlinks above, you will see that the current behavior is quite painful for IDEs in multi-workspace repos.

I can try RUSTFLAGS but then the problem is that all builds inside and outside the IDE need to be somehow configured to use the same flags.

[weihanglo]

Sorry for not being more clear 🙇🏾

By workspace root I mean the root path of either a Cargo workspace or a non-workspace Cargo package. (Just realized VS Code also has its own workspace definition 😅).

Let's look into miri script in rust-lang/miri and compiler/rustc_codegen_cranelift in rust-lang/rust. Here are what I found¹ (You may already know 😆):

• Since rust-lang/miri is not a Cargo workspace, when invoking cargo check --manifest-path ./cargo-miri, rustc invocations will be resolved relatively to ./cargo-miri. My impression is that if you run cargo check --mainfest-path src/tools/miri/cargo-miri/Cargo.toml, you'll get diagnostics from rust-lang/rust root.
• compiler/rustc_codegen_cranelift is excluded from rustc workspace, so any rustc invocations will be resolved from its own package root. So is src/bootstrap.

Changing the behaviour of --manifest-path is definitely a breaking change. Would it help if Cargo has a flag to forced print absolute paths, such as what #5450 and #11043 propose?

Footnotes

1. FYI, I use cargo locate-project --workspace to interactively check whether a package resides in a workspace. ↩

[RalfJung]

The situation with these multi-workspace (or multi-crate-no-workspace) git repos is that they come with a single script that does all the building (./miri or ./x.py). Right now when ./miri or ./x.py prints a path it might be relative to whatever (different errors can even be relative to different paths), which is already ambiguous for people consuming their output and a big problem for tools, such as IDEs, consuming their output.

[jyn514]

• My impression is that if you run cargo check --mainfest-path src/tools/miri/cargo-miri/Cargo.toml, you'll get diagnostics from rust-lang/rust root.

This is not the case. Bootstrap runs all cargo processes from the rust-lang/rust root but still gets the truncated file paths.