Tracking issue for Path Prefix Remapping

[michaelwoerister]

This feature was originally requested in #38322. The PR that implements this in its unstable form is #41508. This will eventually become stable if the testing phase goes well.

[brson]

What's the next step to stabilize this? Looks like it probably won't be stable for 1.20?

[michaelwoerister]

Good question. I did not heard any complaints about the way things currently work -- which I interpret as everybody being happy :).

Some of the people initially interested in the feature were @jmesmon, @infinity0, @sanxiyn, and @jsgf. Do you have any feedback?

Other than that, two open topics are:

• The documentation (currently in the unstable book) needs a revamp. @jsgf found it confusing, IIRC.
• The exact form of the CLI has seen some discussion but there was no clear agreement on what would be best. The current form is -Zremap-path-prefix-from=_, -Zremap-path-prefix-to=_. The could be transformed to
  • -Cremap-path-prefix-from=_, -Cremap-path-prefix-to=_ or
  • --remap-path-prefix-from=_, --remap-path-prefix-to=_ or
  • something else altogether.

I personally would be fine with either of the first two options.

cc @rust-lang/dev-tools

[infinity0]

I haven't tested this yet but I'm still interested. When I get a chance, I'll test it with 1.19 in Debian and see if we get a reproducible build.

[oli-obk]

We use it in clippy for making our tests' stderr output OS independent. Works like a charm: https://github.com/Manishearth/rust-clippy/blob/master/tests/examples.rs#L29

[infinity0]

Is the duplication of the path with / and \ really necessary? I thought the stripping algorithm worked on whole-path components, so that trailing directory separators shouldn't be necessary.

[oli-obk]

Maybe it changed. But I had to implement it this way, otherwise it wouldn't work

[michaelwoerister]

I thought the stripping algorithm worked on whole-path components, so that trailing directory separators shouldn't be necessary.

The current implementation works on plain strings. It does not try to interpret them as paths.

[infinity0]

Oh right. I was going by the code at the bottom of this older comment, I didn't notice you had gone back to plain string matching. What was the reason? I know GCC also do plain string matching, but I actually prefer path-level matching because it would be easier to use. This cross-platform duplication issue is a further example in that area.