-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add unstable -Zroot-dir flag to configure the path from which rustc should be invoked #14752
Conversation
r? @weihanglo rustbot has assigned @weihanglo. Use |
146cc8a
to
a3932ea
Compare
a3932ea
to
cdd0060
Compare
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. |
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.
I'm afraid I don't understand this sentence. Which part does "rather than" refer to? |
cdd0060
to
d21bf01
Compare
I have now painted this in the "Set the root directory relative to which paths are printed (defaults to workspace root)" |
ad2636d
to
d488912
Compare
Seems like the path prefix stripping is not working on Windows... not quite sure how to debug this, without access to a Windows machine. :/ |
dbe5d5c
to
2072be5
Compare
oops I had forgotten to remove the |
2072be5
to
e452dd6
Compare
e452dd6
to
3cf582b
Compare
Something will eventually be needed in stable.
|
…should be invoked
3cf582b
to
c2be327
Compare
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
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. 🎉 |
@@ -783,6 +784,7 @@ unstable_cli_options!( | |||
profile_rustflags: bool = ("Enable the `rustflags` option in profiles in .cargo/config.toml file"), | |||
public_dependency: bool = ("Respect a dependency's `public` field in Cargo.toml to control public/private dependencies"), | |||
publish_timeout: bool = ("Enable the `publish.timeout` key in .cargo/config.toml file"), | |||
root_dir: Option<PathBuf> = ("Set the root directory relative to which paths are printed (defaults to workspace root)"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did my best at guessing the format and organization here, please have a look.
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. |
Thanks! @bors r+ |
☀️ Test successful - checks-actions |
Update cargo 18 commits in e75214ea4936d2f2c909a71a1237042cc0e14b07..0310497822a7a673a330a5dd068b7aaa579a265e 2024-10-25 16:34:32 +0000 to 2024-11-01 19:27:56 +0000 - Add more metadata to `rustc_fingerprint` (rust-lang/cargo#14761) - test(rustfix): switch to a simpler case for dedup-suggestions (rust-lang/cargo#14765) - chore(deps): update rust crate security-framework to v3 (rust-lang/cargo#14766) - chore(deps): update rust crate gix to 0.67.0 (rust-lang/cargo#14762) - fix(util): Respect all `..`s in `normalize_path` (rust-lang/cargo#14750) - test(doc): Resolve flaky test (rust-lang/cargo#14760) - refactor(test): Remove dead 'expect_stdout_contains_n' check (rust-lang/cargo#14759) - add unstable -Zroot-dir flag to configure the path from which rustc should be invoked (rust-lang/cargo#14752) - docs(resolver): Further v3 prep (rust-lang/cargo#14753) - fix: track version in fingerprint dep-info files (rust-lang/cargo#14751) - test: Remove unused msrv-policy (rust-lang/cargo#14748) - download targeted transitive deps of with artifact deps' target platform (rust-lang/cargo#14723) - Remove requirement for --target when invoking Cargo with -Zbuild-std (rust-lang/cargo#14317) - docs(fingerprint): document the encoding of Cargo's depinfo (rust-lang/cargo#14745) - Allow build scripts to report error messages through `cargo::error` (rust-lang/cargo#14743) - fix(publish): Downgrade version-exists error to warning on dry-run (rust-lang/cargo#14742) - fix: clean up for deprecated and removed commands (rust-lang/cargo#14739) - Deprecate `cargo verify-project` (rust-lang/cargo#14736)
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. :)