add unstable -Zroot-dir flag to configure the path from which rustc should be invoked

[RalfJung]

This implements the proposal described here: we add a new flag, for now called -Zroot-dir, that configures the directory relative to which rustc is given the crate root filenames to build. (Files outside this directory are passed absolutely.)

This is necessary to be able to fix (no github don't close that issue yet) rust-lang/rust#128726: in multi-workspace repositories that use scripts to manage a whole bunch of cargo invocations, currently the output cargo+rustc produce is often hard or even impossible to interpret for both human and machine consumption. This is because directories in the output are always relative to the workspace root, but when cargo is invoked many times for different workspaces, it is quite unclear what the workspace root is for the invocation that failed.

So I suggest we should have a new flag that the build script in such a repo can set to the consistent "root dir" that the user would recognize as such (e.g., the root of the rustc source tree), and all paths emitted by cargo and rustc should be relative to that directory.

I don't know all the places that cargo itself emits paths (if any), but this PR changes the way we invoke rustc to honor the new flag, so all paths emitted by rustc will be relative to the -Zroot-dir.

See rust-lang/rust#132390 for the changes needed in rustc bootstrap to wire this up; together, that suffices to finally properly show errors in RA for all parts of the rustc src tree. :)

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[RalfJung]

@epage indicated here that they'd be okay with unstable experimentation, so I hope this is sufficient from a procedural standpoint.

[epage]

@epage indicated #9887 (comment) that they'd be okay with unstable experimentation, so I hope this is sufficient from a procedural standpoint.

Something that isn't clear from the PR that was in my post is that I specifically called out a feature that is intended to be unstable only. Granted, I worry this will take the pressure off of fixing this for everyone, rather than a rustc-only fix.

[RalfJung]

Something that isn't clear from the PR that was in my post is that I specifically called out a feature that is intended to be unstable only.

I think this will eventually be needed on stable: there's clearly a missing feature in cargo here (letting users control the relative paths emitted during the build, a feature that got removed in #4788). However, the most pressing need is fixing rust-lang/rust#128726 so that one can finally get proper RA feedback for rustc library work again (I am holding off writing certain PRs as it's just annoyingly painful to work on the library right now) -- and an unstable-only flag is enough for that. As you can see the patch is fairly simple, so it's hard to imagine a better solution for the immediate problem rustc has. If the alternative is having cargo rewrite rustc output to adjust the base paths are relative too (which will need a lot closer coordination between rustc and cargo than we have today to identify which part of the output is a path), then that will definitely be a lot more work; it also fundamentally alters the relationship between rustc and cargo in terms of how output is handled so I'm not convinced it is actually a better solution.

But anyway, if we have to label this a short-term unstable hack to make it land, I am fine with that. I want to get back to rustc development again, this patch is just meant to make that possible. You asked it to be "not be too invasive"; given the size of the patch I hope it qualifies.

Granted, I worry this will take the pressure off of fixing this for everyone, rather than a rustc-only fix.

I'm afraid I don't understand this sentence. Which part does "rather than" refer to?

[RalfJung]

bikeshed the name of the flag

I have now painted this in the -Zroot-dir color. That works best with the current flag description, I think:

"Set the root directory relative to which paths are printed (defaults to workspace root)"

[RalfJung]

Seems like the path prefix stripping is not working on Windows... not quite sure how to debug this, without access to a Windows machine. :/

[RalfJung]

oops I had forgotten to remove the canonicalize... let's hope that is enough for Windows.

[epage]

I think this will eventually be needed on stable: there's clearly a missing feature in cargo here

Something will eventually be needed in stable.

• We need to find a way to improve the default of what gets rendered
• If we make it further configurable from that default, it likely should live in config somehow (templated variable like we want to do with build/target dirs?)

[RalfJung]

You seem to have a larger design space in mind here than I realized -- is that spelled out anywhere? #9887 doesn't have a lot of concrete ideas, the only ones I could find are

• what is being implemented here
• have cargo translate the output so rustc is always invoked from the workspace root but diagnostics are printed relative to the working dir cargo is invoked from

Anyway, as I said I am fine with this being unstable without a clear path to stabilization. But I think we have to do something to make rustc development more pleasant, and this is the most actionable path forward I can see. (Having cargo translate paths is quite complicated to get right and has some open design questions itself, like how cargo should know about paths embedded in the human-readable part of a diagnostic.)

I have done some git history surgery and I think it now has the commit structure you asked for. I also wrote the corresponding rustc patch and confirmed that this actually works -- I am finally seeing library errors in my IDE again. 🎉
So this should be ready for review.

[epage]

I'm sorry, I forgot to call out that we need an entry in https://doc.rust-lang.org/cargo/reference/unstable.html

You can find it in https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/unstable.md

[RalfJung]

I did my best at guessing the format and organization here, please have a look.

[epage]

You seem to have a larger design space in mind here than I realized -- is that spelled out anywhere? #9887 doesn't have a lot of concrete ideas, the only ones I could find are

Not really. I think it would be great for us to always show diagnostics relative to the current working directory. How we do that is less important (re-render diagnostics, add a flag to rustc to re-parent paths, etc).

If there remain use cases after that, then we can explore something else. People generally bring up a CLI for this but I think config is more relevant as I'd like us to reserve stuff for the CLI that is commonly used. The templating part is an idea I came up with on the fly as config can be as static or dynamic as the user wants and having a template helps for if the user wants something specific relative to something else.

[epage]

Thanks!

@bors r+

[bors]

📌 Commit 0f80faf has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0f80faf with merge 40d804b...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 40d804b to master...