-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Updates to path source walking. #8095
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I left a comment about the change in behavior, but I think this should be fine to land myself.
src/cargo/sources/path.rs
Outdated
@@ -162,50 +175,59 @@ impl<'cfg> PathSource<'cfg> { | |||
&self, | |||
pkg: &Package, | |||
root: &Path, | |||
filter: &mut dyn FnMut(&Path) -> CargoResult<bool>, | |||
filter: &mut dyn FnMut(&Path, bool) -> CargoResult<bool>, | |||
) -> Option<CargoResult<Vec<PathBuf>>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW I know you aren't responsible for this but this return type seems pretty wonky nowadays and it may be best to switch the option/result so ?
and normal idiomatic error handling could be used here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
return Some(self.list_files_git(pkg, &repo, filter)); | ||
} | ||
} | ||
let repo = match git2::Repository::discover(root) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we historically actually did this but at some point backed away from it. That being said my mind here is quite fuzzy and I don't really remember the details (nor with some searching can I find anything).
The best I can remember is that folks sometimes have their whole $HOME
dir as a git repo and they did or didn't want that messing with Cargo. That being said this here is only being used to list the files within a repo for a package we already know, which seems like it's basically just respecting .gitignore
, right? If that's the case I can't really think right now how this can go astray...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷 Maybe play it safe and wait till next week to merge this so that it gets in the next release and gets the maximum amount of time on nightly?
src/cargo/sources/path.rs
Outdated
let repo_safe_path = repo_relative_path | ||
.join("Cargo.toml") | ||
.to_string_lossy() | ||
.replace('\\', "/"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have submitted rust-lang/git2-rs#549 as an upstream fix for this. I think it might be good to wait to merge that, then this can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcrichton would you mind publishing a new git2 release, and then I can remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
er oops, done now!
Ok sounds good to me to wait to merge this next week |
☔ The latest upstream changes (presumably #8124) made this pull request unmergeable. Please resolve the merge conflicts. |
Looks like windows may have some different output orderings? |
Updated git2 to address the Windows issue. |
📌 Commit 25715e4 has been approved by |
☀️ Test successful - checks-azure |
Update cargo 11 commits in 8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca..90931d9b31e8b854522fed00916504a3ac6d8619 2020-04-21 18:04:35 +0000 to 2020-04-28 01:56:59 +0000 - Use associated constants directly on primitive types instead of modules (rust-lang/cargo#8077) - Clear `RUSTDOCFLAGS` before running tests (rust-lang/cargo#8168) - Fix warning for `resolve` mismatch in workspace. (rust-lang/cargo#8169) - Fix flaky linking_interrupted test. (rust-lang/cargo#8162) - Fixed some unnecessary borrows and clones. (rust-lang/cargo#8146) - Added warning when using restricted names in Windows. (rust-lang/cargo#8136) - Add changelog about dylib uplift. (rust-lang/cargo#8161) - Mention that cargo_metadata can parse json messages (rust-lang/cargo#8158) - Re-enable rustc-info-cache test again (rust-lang/cargo#8155) - Updates to path source walking. (rust-lang/cargo#8095) - Bump to 0.46.0, update changelog (rust-lang/cargo#8153)
Fix error with git repo discovery and symlinks. There are some cases where Cargo would generate an error when attempting to discover if a package is inside a git repo when the git repo has a symlink somewhere in its ancestor paths. One way this manifests is with `cargo install --git ...` where the given repo has a `build.rs` script. Another scenario is `cargo build --manifest-path somelink/Cargo.toml` where `somelink` is a symlink to the real thing. The issue is that libgit2 is normalizing paths and removing symlinks, but the path Cargo uses is the path with symlinks. This was introduced in #8095. The solution is to try to canonicalize both paths when trying to get a repo-relative path. If that fails for whatever reason, it shouldn't generate an error since this is just a "best effort" attempt to use git to list package files. Fixes #8183
This is a collection of loosely related changes to path source walking:
package.exclude
patterns to match directories. Previously, the walker would recurse into the directory, and skip every file. Instead, just skip the whole directory. This can be helpful if the directory is not readable, or otherwise want to avoid walking.Cargo.toml
to be in root of a git repo in order to use git to guide the selection. I'm not sure I understand the original reasoning that (any)Cargo.toml
had to reside next to the.git
directory.The last is a moderately risky change, since it's hard to predict how this might affect more complex project layouts or new interactions with
.gitignore
that didn't exist before. Also, I'm wondering if it should just ignore if it fails to open the repo instead of emitting an error?Closes #1729
Closes #6188
Closes #8092