Normalize the target paths

[linyihai]

What does this PR try to resolve?

This adds a struct AbsolutePathTomlTarget to contruct the absolute path for the TargetToml, and apply the paths::normalize to eliminate the relative part.

Fixes #14227

How should we test and review this PR?

Add a test originted from the issue, and fixing it in the next commit.

Additional information

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

This PR does it during the conversion from TomlBinTarget to Target. Previously, #13729 did this during prepare_for_publish. I wonder if we could consolidate these by moving both to the resolve phase.

Also, this needs to be applied to all targets like #13729 did.

[linyihai]

This PR does it during the conversion from TomlBinTarget to Target. Previously, #13729 did this during prepare_for_publish. I wonder if we could consolidate these by moving both to the resolve phase.

Also, this needs to be applied to all targets like #13729 did.

In the read_manifest I had applied the paths::normalize_path to the normalized_toml.

But it is not very aceptable for custom build, see https://github.com/rust-lang/cargo/actions/runs/10760922235/job/29839507217, because custom build can be outside the current package, the .. will be stripped after normalized.

I also want to apply the normalize_path_sep to the targets in normalized_toml, but it fails. see https://github.com/rust-lang/cargo/actions/runs/10767799732/job/29855771840, the rustc will still output \\src\\lib, but the cargo is src/lib.rs

[epage]

But it is not very aceptable for custom build, see https://github.com/rust-lang/cargo/actions/runs/10760922235/job/29839507217, because custom build can be outside the current package, the .. will be stripped after normalized.

Hmm, sounds like normalize_path expects the path to be absolute. We should document and maybe add an assert about that.

That also makes me question using it elsewhere. I forgot that we leave these paths relative. I wonder if we should make the absolute during normalization and relative during publish.

[linyihai]

I wonder if we should make the absolute during normalization and relative during publish.

It's not work for vendor, the absolute path of the vendor contain the vendor project path, which is hard to strip it.

Previously, #13729 did this during prepare_for_publish. I wonder if we could consolidate these by moving both to the resolve phase.

This way is trickier than I thought.

[linyihai]

r? @epage

I wonder if we should make the absolute during normalization and relative during publish.

See my PR description, I think this problem has been improved, please continue to review and leave valuable comments

[epage]

See my PR description, I think this problem has been improved, please continue to review and leave valuable comments

Looking at

This adds a struct AbsolutePathTomlTarget to contruct the absolute path for the TargetToml, and apply the paths::normalize to eliminate the relative part.

its telling me what its doing. What I'm wondering is why this route was chosen. AbsolutePathTomlTarget seems like a fairly invasive change for what I'd expect.

[bors]

☔ The latest upstream changes (presumably #14591) made this pull request unmergeable. Please resolve the merge conflicts.