Fix -Zremap-path-scope rmeta handling by Urgau · Pull Request #139550 · rust-lang/rust (original) (raw)

After more investigation I was finally able to figure out the real issue, when we embed the paths in the rmeta files we call PathMapping::to_embeddable_absolute_path, that function does the necessary to create a remapped path when possible BUT when doing so that function does not keep the original un-remapped path.

This was done before -Zremap-path-scope introduction and means that when we are in a subsequent crate we only have access to the remapped path even through we might want the un-remapped path (depending on the remap path scope), which lead to the issue described in #139217 where the path of the dependency was un-conditionaly the remapped one, because that's all we got.

I've added to PathMapping and PathMapping::to_embeddable_absolute_path some logic to keep the local path when not all remap path scope are requested, as to keep rlib and rmeta free of local path when only --remap-path-prefix is passed (privacy and build reproducibility reasons).

@rustbot labels -S-blocked -S-waiting-on-author +S-waiting-on-review