--remap-path-prefix has no effect

[Sebi2020]

I tried this code: Not applicable

I expected to see this happen: --remap-path-prefix should rewrite paths to the new prefix, but fails.

Instead, this happened: Paths are still persistent in the binary or rlib

Meta

Steps to reproduce:

1. Build a lib or program on windows with rustc 1.54.0 and msvc with --remap-path-prefix in .cargo/config.toml (project directory)
2. Path prefix is not applied. Old paths still present in binary and/or rlib.

I tried C:\path\to\project and C:/path/to/project in the from path. Both failed to work.

rustc --version --verbose:

binary: rustc
commit-hash: a178d0322ce20e33eac124758e837cbd80a6f633
commit-date: 2021-07-26
host: x86_64-pc-windows-msvc
release: 1.54.0
LLVM version: 12.0.1

Backtrace: Not applicable

[SkiFire13]

I can't seem to fully reproduce this.

My C:\path\to\project\.cargo\config.toml:

[build]
rustflags = ["--remap-path-prefix", "C:\\path\\to\\project=nothing_to_see_here"]

I've also tried with the following and the results are the same:

[build]
rustflags = ["--remap-path-prefix", "C:/path/to/project=nothing_to_see_here"]

Building a lib results in a .rlib file that doesn't contain C:\path\to\project.

Building a binary however results in a .exe file that contains C:\path\to\project\target\release\deps\crate_name.pdb. In general however paths seem to be correctly mapped, for example if I set RUST_BACKTRACE=1 and then panic in a debug build the backtrace will show the path starting with nothing_to_see_here.

Edit: I forgot to use the same anonymous path... well, nobody will care if I have a local rust-playground crate

[ChrisDenton]

Building a binary however results in a .exe file that contains C:\path\to\project\target\release\deps\crate_name.pdb

Removing this requires an msvc linker flag. E.g. /PDBALTPATH:nothing_to_see_here

[SkiFire13]

Removing this requires an msvc linker flag. E.g. /PDBALTPATH:nothing_to_see_here

I can confirm that with either -Clink-arg=/PDBALTPATH:nothing_to_see_here, -Clink-arg=/DEBUG:NONE or -Zstrip=debuginfo the executable no longer contains that path. However this is neither intuitive nor documented. In particular the rustc book claims that --remap-path-prefix remaps path prefixes in all output, including "debug information", and doesn't mention this caveat with msvc at all.

[Sebi2020]

I can't seem to fully reproduce this.

My C:\path\to\project\.cargo\config.toml:

[build]
rustflags = ["--remap-path-prefix", "C:\\path\\to\\project=nothing_to_see_here"]

I've also tried with the following and the results are the same:

[build]
rustflags = ["--remap-path-prefix", "G:/WorkSpace/rust-playground=nothing_to_see_here"]

Maybe I had specified the flag in the wrong way. I've used ["--remap-path-prefix=G:\\WorkSpace\\rust-playground=G:/"] not the space separated version. not with 2 arguments. The unstable version used to specifiy it like --remap-path-prefix=from=to

[Sebi2020]

@SkiFire13 Even with your invocation my rlib contains the follwing paths:

AC:\Users\[user with space]\Desktop\ArcVec\arc_iterator\src\lib.rs
JC:\Users\[user with space]\Desktop\ArcVec\arc_iterator\src\arc_iterator.rs

.config/cargo.toml contains:

[build]
rustflags = ["--remap-path-prefix","C:\\Users\\[user with space]\\Desktop\\ArcVec\\arc_iterator\\src\\=C:\\"]

I've also tried:

rustflags = ["--remap-path-prefix","C:\\Users\\[user with space]\\Desktop\\ArcVec\\arc_iterator\\src=C:\\"]
...
rustflags = ["--remap-path-prefix","C:/Users/[user with space]/Desktop/ArcVec/arc_iterator/src/=C:/"]

[SkiFire13]

After a couple of local tests I think the problem is that prefixes that end up inside the crate directory (like yours that end with /src) are not currently handled correctly. #85344 seems to be aimed to fix this problem, although I haven't tested it. @Sebi2020 can you check if removing the trailing \src fixes your issue?

[Sebi2020]

After a couple of local tests I think the problem is that prefixes that end up inside the crate directory (like yours that end with /src) are not currently handled correctly. #85344 seems to be aimed to fix this problem, although I haven't tested it. @Sebi2020 can you check if removing the trailing \src fixes your issue?

You're right, stripping the src suffix caused the compiler to replace the paths. But as you mentioned this is not the case for executables build with msvc. (btw. the compiler produces debug symbols for release builds too without a manually added -Clink-arg=/DEBUG:NONE).

And I've (maybe) found a second bug. Originally my crate was a subcrate of another root crate. Both crates contained a .config/config.toml in their project root with --remap-path-prefix. If you now issue the build command inside the sub-crate cargo uses the rustflags for the root crate too. I'm not sure if specifiying --remap-path-prefix on rustc twice causes the compiler to discard the first declaration or if it keeps a list of remaps. Another question is, if the rustflags are applied when cargo builds the sub crate as a path dependency. I'm not experienced enough to answer this. More tests needed. (btw. a flag which causes rustc to strip build paths without a absolute path specification whould be very helpful. Specifying absolute paths makes the result of the compilation dependent on the local project location).

[SkiFire13]

And I've (maybe) found a second bug. Originally my crate was a subcrate of another root crate. Both crates contained a .config/config.toml in their project root with --remap-path-prefix. If you now issue the build command inside the sub-crate cargo uses the rustflags for the root crate too.

I think that's expected behaviour, Cargo looks for .cargo/config.toml files in subdirectories too (see the cargo book for further details). It also describes how it solves conflicts, in your case rustflags is an array so it joins them.

Anyway I would suggest not to nest crates, instead use a workspace or just put them in the same folder.

I'm not sure if specifiying --remap-path-prefix on rustc twice causes the compiler to discard the first declaration or if it keeps a list of remaps.

I think it keeps a list and the first one to apply wins.

Another question is, if the rustflags are applied when cargo builds the sub crate as a path dependency.

I think only the ones that apply to the final crate are used. Again, if you use a workspace or you put them in the same folder then you can just map that folder and it will work for the other crates as well.

btw. a flag which causes rustc to strip build paths without a absolute path specification whould be very helpful. Specifying absolute paths makes the result of the compilation dependent on the local project location

There's work in progress to make $CARGO_HOME and $PWD automatically expanded so that you can just include them in the .cargo/config.toml, see rust-lang/cargo#5505. There's also a PR open that would allow to automatically trim paths inside the current project directory, see rust-lang/cargo#9407

Finally, if the original issue is solved this should be closed. If you need additional help you may ask on users.rust-lang.org or in https://discord.gg/rust-lang

[Sebi2020]

I would say it's not solved entirely or there should be a separate issue for this one:

Removing this requires an msvc linker flag. E.g. /PDBALTPATH:nothing_to_see_here

I can confirm that with either -Clink-arg=/PDBALTPATH:nothing_to_see_here, -Clink-arg=/DEBUG:NONE or -Zstrip=debuginfo the executable no longer contains that path. However this is neither intuitive nor documented. In particular the rustc book claims that --remap-path-prefix remaps path prefixes in all output, including "debug information", and doesn't mention this caveat with msvc at all.

[SkiFire13]

This issue is already filled with discussions about other problems so I think it's better to open a separate issue.