-
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
feat: implement RFC 3127 -Ztrim-paths
#12625
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
5764df8
to
42377d2
Compare
☔ The latest upstream changes (presumably #12648) made this pull request unmergeable. Please resolve the merge conflicts. |
Do you want a review on this while it is in draft status? |
I would wait for rustc side being reviewed. |
☔ The latest upstream changes (presumably #12768) made this pull request unmergeable. Please resolve the merge conflicts. |
6a63947
to
b37054d
Compare
let commit_hash = &cx.bcx.rustc().commit_hash; | ||
let mut remap = OsString::from("--remap-path-prefix="); | ||
// TODO(trim-paths): what is the correct prefix for sysroot? does rustup affect this? | ||
remap.push(sysroot); |
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.
What's the correct remap prefix for sysroot, and how to setup a test case for it?
I've checked rustup, Debian, and Fedora. All of them put the rust-src under [sysroot]/lib/rustlib/src/rust
. From what I can tell, -Zbuild-std
is also hardcoded with this path.
@Urgau do you have any insight?
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.
What's the correct remap prefix for sysroot
and how to setup a test case for it?
Well you could have a Rust fn main() { panic!("something"); }
with RUST_BACKTRACE=1
and see the resulting backtrace and assert that it doesn't contain the un-remapped sysroot.
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.
Thanks for the tip!
Unfortunately I've tried panic!
backtrace and it has already remapped even without -Ztrim-paths
😞.
0: std::panicking::begin_panic
at /rustc/cd674d61790607dfb6faa9d754bd3adfa13aea7c/library/std/src/panicking.rs:638:12
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.
Hum, the mapping is done by bootstrap
here, I wonder if we should remove/disable it since Cargo will now do it.
Or maybe instead of disabling it you could do the inverse and demap in debug?
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.
The desired behavior is mentioned in the RFC
- https://rust-lang.github.io/rfcs/3127-trim-paths.html#handling-sysroot-paths
- https://rust-lang.github.io/rfcs/3127-trim-paths.html#changing-handling-of-sysroot-path-in-rustc
To follow the RFC, yes, we might want to disable it in bootstrap.
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.
Me and Urgau had a chat on this. Urgau pointed out changing the bootstrap this may require -Ztrim-paths
being stabilized, and may leak CI details into all pre-built std, core…. This is something requiring to collaborate with T-bootstrap. We'll postpone it for this pull request.
let mut remap = OsString::from("--remap-path-prefix="); | ||
// Remapped to path relative to workspace root: | ||
// | ||
// * path dependencies under workspace root directory |
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.
The RFC only mentions about mapping the current package, which doesn't take workspaces into account:
For the the current package (where the current working directory is in), from the the absolute path of the package root to empty string. For other packages, from the absolute path of the package root to
[package name]-[package version]
.
Here we expand the RFC a bit: always remap from the workspace root to empty string. When dealing with compilations, Cargo always handle the workspace as a whole instead of a single member. We might not want an exception for -Ztrim-paths
.
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.
For me, the main question of whether to be relative to workspace or package root is if there'd be ambiguity. Since we have name+version, I'm guessing not.
[RUNNING] [..]rustc [..]-Zremap-path-scope=diagnostics --remap-path-prefix=[..]/lib/rustlib/src/rust=/rustc/[..] --remap-path-prefix=[CWD]= [..]", | ||
) | ||
.run(); | ||
} |
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'd like to set up a smoke test against debug symbol, so that we can make sure they are sanitized. I can follow what rustc does by using objdump
. Is there any better way to verify it? What about cross-platform tests?
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.
Ended up using readelf
. Now we have covered Linux for object
option. I think that's pretty acceptable at this stage. We can add more tests for macOS and Windows later.
-Ztrim-paths
This is ready for review. Not 100% complete but good for shipping as a nightly feature. |
8862b05
to
ae2a95e
Compare
if let Some(trim_paths) = trim_paths { | ||
trim_paths_args(cmd, cx, unit, &trim_paths)?; | ||
} |
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.
Should this also be included in rustdoc to handle the diagnostics stripping (and same with doctests)?
(Though I still don't 100% understand the purpose of diagnostic remapping.)
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 don't think there is such an option for rustdoc
. Did I miss something?
Maybe this could be put in "unresolved questions" in RFC 3127 tracking issue.
$ rustdoc +nightly -vV
rustdoc 1.75.0-nightly (608e9682f 2023-10-29)
binary: rustdoc
commit-hash: 608e9682f0a6482903de8d3332770104a0ad943c
commit-date: 2023-10-29
host: aarch64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.3
$ rustc --remap-path-prefix
error: Argument to option 'remap-path-prefix' missing
$ rustdoc --remap-path-prefix
error: Unrecognized option: 'remap-path-prefix'
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.
Yea, leaving that as an open issue sounds good. The rustdoc argument parser would just need to be updated.
Though, before that I would like to better understand why the diagnostic option exists and when someone would want to turn it on. I can't really follow the discussion from rust-lang/rust#87745 and how that relates to cargo. If we end up not stabilizing "diagnostic" as an option, then I don't have any motivation to do that.
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.
Regarding the diagnostics
option I think it's related to build-systems that create VFS (Virtual File System) or temporary location when building, throwing the all diagnostics path to the wrong location.
warning: unused variable: `unused` | ||
--> bar-0.0.1/src/lib.rs:1:18 | ||
| | ||
1 | pub fn f() { let unused = 0; } | ||
| ^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused` | ||
| | ||
= note: `#[warn(unused_variables)]` on by default", |
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.
Tests can't match on the compiler's output exactly, since it changes too often, and makes it impossible to change (since it would require simultaneously changing both rust-lang/rust and rust-lang/cargo).
I think you can do something like with_stderr_contains("[..]bar-0.0.1/src/lib.rs:1[..]")
to just check the important part.
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.
Thanks for calling this out, and replaced this with with_stderr_line_without
.
src/cargo/util/toml/mod.rs
Outdated
} | ||
} | ||
|
||
impl TomlTrimPaths { |
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.
nit: when i reorganized this file, I put all non-trait impl blocks first
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.
Oh how I missed that. Fixed!
is there any rustfmt or clippy rules to enforce this?
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.
Besides anything Eric brings up, I'm good with merging this. Thanks for moving this along!
The rustc commit hash is required as we'll need it to remap sysroot path to `/rustc/<commit-hash>`, as rustc bootstrap does. See <https://github.com/rust-lang/rust/blob/c2ef3516/src/bootstrap/src/lib.rs#L1113-L1116>. This is optional as the compiler it may be built without a Git repository.
trim-paths is shown as disabled as default in `Debug` impl. Although this doesn't reflect the correct default for `-Ztrim-pthas`, this is no critical as it is only for debugging, and it's a bit tricky to make it more correct.
I haven't done a thorough review, but overall looks good to me. @bors r=epage |
☀️ Test successful - checks-actions |
Update cargo 7 commits in 708383d620e183a9ece69b8fe930c411d83dee27..b4d18d4bd3db6d872892f6c87c51a02999b80802 2023-10-27 21:09:26 +0000 to 2023-10-31 18:19:10 +0000 - refactor(toml): Cleanup noticed on the way to rust-lang/cargo#12801 (rust-lang/cargo#12902) - feat(trim-paths): set env `CARGO_TRIM_PATHS` for build scripts (rust-lang/cargo#12900) - feat: implement RFC 3127 `-Ztrim-paths` (rust-lang/cargo#12625) - docs: clarify config to use vendored source is printed to stdout (rust-lang/cargo#12893) - Improve the margin calculation for the search command's UI (rust-lang/cargo#12890) - Add new packages to [workspace.members] automatically (rust-lang/cargo#12779) - refactor(toml): Decouple parsing from interning system (rust-lang/cargo#12881) r? ghost
What does this PR try to resolve?
Implement RFC 3127 trim paths on Cargo side. The counterpart of the compiler is in rust-lang/rust#115214. The tracking issue for Cargo is #12137.
How should we test and review this PR?
By commits. I would recommend reading the doc first to get the an overview on this.
Things I am uncertain
-Ztrim-paths
#12625 (comment).-Ztrim-paths
being stabilized, and may leak CI details into all pre-built std, core…. This is something requiring to collaborate withT-bootstrap
. We'll postpone it for this pull request.-Ztrim-paths
#12625 (comment)Things to decide (but can postpone to follow-up PRs)
<pkg>-<version>
good enough for all source kinds?SourceId
hash or something instead?-Ztrim-paths
#12625 (comment)Additional information
Things to do:
trim-paths = "all"
andtrim-paths = "none"
but nottrim-paths = ["all", "none"]
.trim-paths = true/false
.dev
andrelease
profile.CARGO_TRIM_PATHS
environment variable for build scripts. (feat(trim-paths): set envCARGO_TRIM_PATHS
for build scripts #12900)--remap-path-prefix
works withrustdoc
invocations (whichrustdoc
need an update)