x.py build changed how paths are printed => hyperlinks (in e.g. emacs) do not work

[pnkfelix]

At some point in the recent past, something in one or more of our tools has broken so that the paths printed during compilation errors/warnings are not presented relative to the current directory.

E.g., when I am building with current directory ~/Dev/Mozilla/rust-mirborrowck/objdir-dbgopt/, via the command ../x.py build --incremental --keep-stage 0 --stage 1 src/libstd, I now get output with errors like this:

Copying stage0 test from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling rustc_mir v0.0.0 (file:///home/pnkfelix/Dev/Mozilla/rust-mirborrowck/src/librustc_mir)
error: expected one of `=>`, `if`, or `|`, found `{`
   --> librustc_mir/borrow_check/mod.rs:949:36
    |
949 |             Rvalue::Len(ref place) {
    |                                    ^ expected one of `=>`, `if`, or `|` here

error: aborting due to previous error

error: Could not compile `rustc_mir`.

but the provided path, librustc_mir/borrow_check/mod.rs is meaningless in the context of my current directory; I need it to either be an absolute path, or a relative path like ../src/librustc_mir/borrow_check/mod.rs

[pnkfelix]

This is of course easy for a veteran to work around by manually opening up the files in question, which is why I suspect no one had filed this issue yet. But its probably really bad for a newcomer, and its an annoyance even for veterans.

[Zoxc]

This seems to be due to rust-lang/cargo#4788.

cc @alexcrichton

[alexcrichton]

Yes this is due to the PR @Zoxc linked. We could fix this in rust-lang/rust by moving the Cargo.toml up to the root I believe.

[nikomatsakis]

Drives me crazy. I am currently using ./x.py build 2>&1 | sed s%--> lib%-->src/lib%, but I think that in general running ./x.py should print relative to the directory where you ran the command.

[pnkfelix]

Just as an update: @alexcrichton wrote:

Yes this is due to the PR @Zoxc linked. We could fix this in rust-lang/rust by moving the Cargo.toml up to the root I believe.

But from reading the history of PR #47731 it appears that the strategy of moving Cargo.toml up to the root was not workable...

[jyn514]

@pnkfelix are you still running into this issue? Similar errors in rustdoc print relative to the workspace root, is that the behavior you want? If so I think this can be closed.

error[E0432]: unresolved import `std::ev`
  --> src/librustdoc/lib.rs:62:5
   |
62 | use std::ev;
   |     ^^^^^--
   |     |    |
   |     |    help: a similar name exists in the module: `env`
   |     no `ev` in the root

[jyn514]

I'm going to close this, I think it's since been fixed.