Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use canonical paths for checking equality #3489

Merged
merged 1 commit into from
Jan 10, 2017
Merged

Conversation

matklad
Copy link
Member

@matklad matklad commented Jan 3, 2017

No description provided.

@rust-highfive
Copy link

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

p.build();

assert_that(p.cargo("build").cwd(p.root().join("foo")), execs().with_status(0));
assert_that(p.cargo("build").cwd(p.root().join("bar")), execs().with_status(0));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With current cargo, this invocation will fail with bar believes it is in workspace foo, but foo does not think so. This happens because paths are compared, and they look like foo/Cargo.toml and bar/../foo/Cargo.toml.

@matklad
Copy link
Member Author

matklad commented Jan 3, 2017

@alexcrichton this is a stop-gap solution. A better solution I have in mind is to introduce a CanonicalPath(PathBuf) newtype wrapper, which would enforce this properly. It should solve #3436 in a more principal way and I think it can even pave the way for #3273?

What do you think?

@matklad
Copy link
Member Author

matklad commented Jan 3, 2017

Hm, windows tests fail because canonicalize returns \\?\ flavor of paths on windows. I think it would be better just to implement CanonicalPath idea rather then hunt for each Path on case by case basis. Would you be ok with this solution, or do you have something better in mind?

@alexcrichton
Copy link
Member

It sounds like we may not need literally canonical paths (e.g. a syscall) but perhaps just a normalization instead?

@alexcrichton
Copy link
Member

In general I'm very wary of reinterpreting paths as it seems to always introduce a bug one way or another, so I'd be interested in slicing this down to as few normalized paths as possible if we can.

@matklad
Copy link
Member Author

matklad commented Jan 7, 2017

Yes, that's most reasonable! I've actually tried to find a path normalization crate, but it didn't occur to me that this function may already be present in Cargo :)

@matklad
Copy link
Member Author

matklad commented Jan 7, 2017

Hm, I think there's at least one plausible case where the normalization is not enough. If the filesystem is case-insensitive, paths in members and the one we get walking the tree up may have different case. We had a similar problem in IntelliJ-Rust, and solved it by properly using IntelliJ virtual file system, which abstracts this stuff more or less correctly. Not sure if this can be handled in Cargo without massively complicated implementation.

@alexcrichton
Copy link
Member

@bors: r+

Looks good to me, thanks!

I feel like it's ok if Cargo doesn't dive that deeply into filesystem weirdness. At some point you can also just configure it a little differently and have it work out...

@bors
Copy link
Collaborator

bors commented Jan 10, 2017

📌 Commit 083da14 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jan 10, 2017

⌛ Testing commit 083da14 with merge 7060ca1...

bors added a commit that referenced this pull request Jan 10, 2017
Use canonical paths for checking equality
@bors
Copy link
Collaborator

bors commented Jan 10, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 7060ca1 to master...

@bors bors merged commit 083da14 into rust-lang:master Jan 10, 2017
@matklad
Copy link
Member Author

matklad commented Jan 10, 2017

@alexcrichton an unrelated question: am I correct that using / as path separators for relative paths in Cargo.toml is cross-platform, because Windows API converts / to \ automatically?

@matklad matklad deleted the rel-ws branch January 18, 2017 10:19
@ehuss ehuss added this to the 1.16.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants