Add trim-path cargo manifest option

[Morganamilo]

This option uses rustc's --remap-path-prefix to trim everything above
the package root from the path prefix. Optionally you can also specify a
value to replace the path with.

For example, say you have a project in /home/projects/foo.

Without this option, the filepath for the main file would be:
/home/projects/foo/src/main.rs

By setting trim-path = true this becomes: foo/src/main.rs

By setting trim-path = "/usr/lib/debug/ this becomes: /usr/lib/debug/foo/src/main.rs

This allows the user's home directory to be removed from paths in the
binary. And for distributions to point the paths to where they store
debug code.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Morganamilo]

If accepted I would like to see this enabled by default on release build. Not exactly sure the process to push for that but I've left it off by default for now.

[alexcrichton]

Thanks for the PR! This seems like a reasonable enough implementation and feature for Cargo to have. Personally though I think the naming should somehow be along the lines of "remap-path-prefix" because currently this doesn't really clearly have a connection to that CLI option from rustc.

Additionally I've personally at least wished for some sort of top-level flag to Cargo saying "I want a reproducible build please". I realize that the path issue here is not just reproducibility but also hiding the original source paths from showing up in the final binary, but this is somewhat related to reproducible builds. In any case though this is unstable so we have some time to consider it.

As for turning it on by default for any profile, I think that will need to probably get discussed somewhere else. I don't really know the consequences of a decision like that except for no debuggers will work by default.

[Morganamilo]

Thanks. glad this feature seems to be acceptable.

Personally though I think the naming should somehow be along the lines of "remap-path-prefix" because currently this doesn't really clearly have a connection to that CLI option from rustc.

Personally I don't think there needs to really be a link between the name in cargo and rustc. To me the rustc flag is an implementation detail and doesn't really matter.

As for turning it on by default for any profile, I think that will need to probably get discussed somewhere else. I don't really know the consequences of a decision like that except for no debuggers will work by default.

I'd only like to see it on by default in release mode so that issue is mostly avoided.

[alexcrichton]

Personally I disagree that there is no link between these two flags. Rustc I don't think is just an implementation detail of Cargo, it's sort of the whole point of Cargo to call rustc in the right order and with the right flags. I don't think Cargo should be blazing a trail here given existing precedent in rustc.

[Morganamilo]

What would you prefer the name be then? just remap-path-prefix? Would remap-path-prefix = true be confusing given rustc's option takes a to and from? Also there's some prior art with go using -trimpath.

[alexcrichton]

I don't have a specific name in mind, just a preference that it more obviously relates to remap-path-prefix. Note that for adding this PR to Cargo this will also need tests. I think it's also worth documenting that it's not the package root that's remapped, it's one directory up from the package root that's remapped (in an assumption that crates are contained in directories that imply their name.

[Morganamilo]

I think it's also worth documenting that it's not the package root that's remapped, it's one directory up from the package root that's remapped

Ah yeah, It was originally this but I ended up changing it.

Note that for adding this PR to Cargo this will also need tests

How exactly would I go about testing this? I'm not sure how to actually check the paths have changed.

[alexcrichton]

You might be able to test the output of file!() or look at the output of a binary that panics. I think the remap prefixes affect those paths too.

[Morganamilo]

Ah that's a good idea thanks.

[joshtriplett]

I'd like to propose a slight tweak to the proposed behavior: rather than keeping the directory name above Cargo.toml, let's remap that directory to the name of the crate.

So, for example, if you have abc/xyz/Cargo.toml, and Cargo.toml sets the package name to thecrate, we should remap /path/to/abc/xyz to thecrate.

(As opposed to what sounded like the previous proposal, of mapping /path/to/abc/xyz to xyz.)

[ehuss]

I'm gonna close this due to inactivity. Feel free to reopen or create a new PR when you've got time to work on this again. Thanks!