-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
remap-path-prefix affects dep-info #63329
Copy link
Copy link
Closed
Labels
A-driverArea: rustc_driver that ties everything together into the `rustc` compilerArea: rustc_driver that ties everything together into the `rustc` compilerC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-driverArea: rustc_driver that ties everything together into the `rustc` compilerArea: rustc_driver that ties everything together into the `rustc` compilerC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The
--remap-path-prefixflag affects paths in dep-info files. This causes some problems witth Cargo.Cargo uses these paths to detect if any source file has been modified. Since the common use case for
--remap-path-prefixis to rewrite to some artificial path (like/rustc/$HASHwhich rust distributions use), this causes them to point to non-existent paths, which Cargo cannot check.In some cases, this doesn't matter. Workspace members are built with relative paths which (usually) won't match the remap value. However, registry or vendored paths will get remapped. Cargo won't find the path, so it will always assume it needs to rebuilt, breaking it's rebuild detection.
I think dep-info paths should not be remapped. I think it keeps with the spirit of reproducible builds (the binaries aren't affected, this is just a side-channel build-system file). However, I'm not certain. I also don't know how hard this will be to implement.
Oh, and
-Z binary-dep-depinfodoesn't seem to be affected by--remap-path-prefix.