Bump git2 to 0.15 and libgit2-sys to 0.14
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
Apply GitHub fast path even for partial hashes
### What does this PR try to resolve?
As flagged in https://github.com/rust-lang/cargo/pull/10079#issuecomment-1170940132, it's not great to assume that git SHAs would always be 40-character hex strings. In the future they will be longer.
> Git is on a long-term trajectory to move to SHA256 hashes ([current status](https://lwn.net/SubscriberLink/898522/f267d0e9b4fe9983/)). I suppose when that becomes available/the default it's possible for a 40-digit hex-encoded hash not to be the full hash. Will this fail for that case?
The implementation from #10079 fails in that situation because it turns dependencies of the form `{ git = "…", rev = "[…40 hex…]" }` into fetches with a refspec `+[…40 hex…]:refs/commit/[…40 hex…]`. That only works if the 40 hex digits are the *full* long hash of your commit. If it's really a prefix ("short hash") of a 64-hex-digit SHA-256 commit hash, you'd get a failure that resembles:
```console
error: failed to get `dependency` as a dependency of package `repro v0.0.0`
Caused by:
failed to load source for dependency `dependency`
Caused by:
Unable to update https://github.com/rust-lang/dependency?rev=b30694b4d9b29141298870b7993e9aee10940524
Caused by:
revspec 'b30694b4d9b29141298870b7993e9aee10940524' not found; class=Reference (4); code=NotFound (-3)
```
This PR updates the implementation so that Cargo will curl GitHub to get a resolved long commit hash *even if* the `rev` specified for the git dependency in Cargo.toml already looks like a SHA-1 long hash.
### Performance considerations
⛔ This reverses a (questionable, negligible) benefit of #10079 of skipping the curl when `rev` is a long hash and is not already present in the local clone. These curls take 200-250ms on my machine.
🟰 We retain the much larger benefit of #10079 which comes from being able to precisely fetch a single `rev`, instead of fetching all branches and tags in the upstream repo and hoping to find the rev somewhere in there. This accounts for the entire performance difference explained in the summary of that PR.
🟰 We still skip the curl when `rev` is a **long hash** of a commit that is already previously fetched.
🥳 After this PR, we also curl and hit fast path when `rev` is a **short hash** of some upstream commit. For example `{ git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9" }` would previously have done the download-all-branches-and-tags codepath because `b30694b4d9` is not a long hash. After this PR, the curl to GitHub informs us that `b30694b4d9` resolves to the long hash `b30694b4d9b29141298870b7993e9aee10940524`, and we download just that commit instead of all-branches-and-tags.
### How should we test and review this PR?
I tested with the following dependency specs, using `/path/to/target/release/cargo generate-lockfile`.
```toml
# Before: slow path (fetch all branches and tags; 70K git objects)
# After: fast path (20K git objects)
cargo = { git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9b2914129" }
```
```toml
# Before and after: fast path
cargo = { git = "https://github.com/rust-lang/cargo", rev = "b30694b4d9b29141298870b7993e9aee10940524" }
```
```toml
# Before and after: fast path
cargo = { git = "https://github.com/rust-lang/cargo", rev = "refs/heads/rust-1.14.0" }
```
```toml
# Before and after: same error "revspec 'rust-1.14.0' not found"
# You are supposed to use `branch = "rust-1.14.0"`, this is not considered a `rev`
cargo = { git = "https://github.com/rust-lang/cargo", rev = "rust-1.14.0" }
```
I made sure these all work both with and without `rm -rf ~/.cargo/git/db/cargo-* ~/.cargo/git/checkouts/cargo-*` in between each cargo invocation.
FYI `@djc`
Update non-ASCII crate name warning message
This PR fixes an outdated warning when initializing crates sometimes.
### What does this PR try to resolve?
Per [a Zulip convo](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Non-ASCII.20crate.20name.20status/near/294876491) on the topic, non-ASCII crate names are no longer allowed on any toolchain since https://github.com/rust-lang/rust/pull/73305, during the `non_ascii_idents` feature's development. Cargo however tells the user that they are accepted on Nightly. Rust and Cargo should agree on this point to avoid future confusion.
### How should we test and review this PR?
This should be covered by the existing test that was changed but if desired its easy to test with a checkout:
```
Running `/Users/fox/x/Forks/cargo/target/release/cargo init 'ああああ'`
warning: the name `ああああ` contains non-ASCII characters
Non-ASCII crate names are not supported by Rust.
```
Add more tests for aggressive or precise update
### What does this PR try to resolve?
When I was working on https://github.com/rust-lang/cargo/pull/10988, I found there is no test for the aggressive update. So I added it.
Also, I added a test for precise update to make sure it won't force update the deps of SPEC.
### How should we test and review this PR?
Unit tests.
Walkdir's [`filter_entry()`][1] won't call the predicate if the entry
is essentially an `Err` from its underyling `IntoIter`. That means
Cargo hasn't had a chance to call `filter` on an entry that should be
excluded but eventually return an `Err` and cause the loop to stop.
For instance, a broken symlink which should bee excluded by `filter`
will generate an error since `filter` closure is not called with it.
The solution is calling `filter` if an error occurs with a path
(because it has yet been called with that path).
If it's exactly excluded, ignore the error.
[1]: abf3a15887/src/lib.rs (L1042-L1058)
Improve error message for wrong target names
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/10982
We can print all available targets for users.
### How should we test and review this PR?
- [x] unit test
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
Warning when precise or aggressive without -p flag
### What does this PR try to resolve?
ref https://github.com/rust-lang/cargo/issues/10919.
Warning when precise or aggressive without -p flag. It will be a hard error in future.
### How should we test and review this PR?
- Unit test.
Improve error message for an array value in the manifest
Fixes https://github.com/rust-lang/cargo/issues/10942
The error message will be:
```
error: failed to parse manifest at `/Users/..`
Caused by:
invalid type: string "Ky", expected an array for key `package.authors`
```
Fix file locking being not supported on Android raising an error
This PR fixes#10972 by not failing Cargo operations when the `target_os` is Android and file locking is being reported as not being implemented by the kernel.
I am sadly unable to actually test this at the moment, since despite my best efforts I am not able to get Cargo actually cross-compiled for Android (aarch64-linux-android).
I however don't see any reason why this wouldn't work. `target_os` is "android" on Android and not "linux".
[docs] Remove extra "in" from `cargo-test.md`
Removes an extra "in" from doc src/doc/src/commands/cargo-test.md
Successor to #10971 without bungled merge
Enable two windows tests
These two tests were disabled on Windows a long time ago. AFAICT, the reasons are no longer relevant, and it should be safe to enable these tests. See each commit for a more detailed exposition.
Improve error msg for get target runner
Actually, we'll get this config from three places. So this msg may be confusing when you set it up in `.cargo/config.toml` or pass it by `--config`.
We already printed the location of the config, so I think it's OK to change it to `configurations`.
Ensure rustc-echo-wrapper works with an overridden build.target-dir
Without this when running with an overridden target-dir there are about a dozen test failures like
```console
> mkdir .cargo
> echo '[build]\ntarget-dir = "not-target"' > .cargo/config
> cargo test -- fix::does_not_crash
---- fix::does_not_crash_with_rustc_wrapper stdout ----
running `/home/nemo157/sources/cargo/not-target/debug/cargo build`
running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
thread 'fix::does_not_crash_with_rustc_wrapper' panicked at '
test failed running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
error: process exited with code 101 (expected 0)
--- stdout
--- stderr
error: failed to run `rustc` to learn about target-specific information
Caused by:
could not execute process `/home/nemo157/sources/cargo/not-target/tmp/cit/rustc-echo-wrapper/target/debug/rustc-echo-wrapper rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (never executed)
Caused by:
No such file or directory (os error 2)
', tests/testsuite/fix.rs:1228:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Because the `rustc-echo-wrapper` is compiled to `not-target/debug/rustc-echo-wrapper`.
This is resolved by forcing the target-dir to be a manifest-relative one for this specific build.
Switch back to `available_parallelism`
This reverts commit 8345cf5037 now that https://github.com/rust-lang/rust/pull/97925 is merged.
Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.
This reverts commit 8345cf5037. Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.
Only override published resolver when the workspace is different
### What does this PR try to resolve?
Ensures when publishing a package that uses an implicit `resolver = "1"` to maintain an MSRV before the `resolver` key was stabilized the implicitness is retained rather than being turned into an explicit setting.
fixes#10954 (assuming that the workspace and its packages are configured with a consistent resolver)
