Enable some tests on windows.
This enables some more tests on windows that were disabled because `echo` is not always available. It's pretty easy to make a custom `echo`, so that's what this does. I'm generally not comfortable with disabling tests just because there is an inconvenience like this.
Fix `cargo fix --edition` on stable.
I accidentally missed the removal of a `-Zunstable-options` flag in #9800. This prevented `cargo fix --edition` from working on stable/beta.
rev = "refs/pull/𑑛/head"
GitHub exposes a named reference associated with the head of every pull request. For example, you can fetch *this* pull request:
```console
$ git fetch origin refs/pull/9859/head
$ git show FETCH_HEAD
```
Usually when I care about pulling in a patch of one of my dependencies using `[patch.crates-io]`, this is the ref that I want to depend on. None of the alternatives are good:
- `{ git = "the fork", branch = "the-pr-branch" }` — this is second closest to what I want, except that when the PR merges and the PR author deletes their fork, it'll breaks.
- `{ git = "the fork", rev = "commithash" }` — same failure mode as the previous. Also doesn't stay up to date with PR, which is sometimes what I want.
- `{ git = "the upstream", rev = "commithash" }` — doesn't work until the PR is merged or the repo owner creates a named branch or tag containing the PR commit among its ancestors, because otherwise the commit doesn't participate in Cargo's fetch.
- `{ git = "my own fork of PR author's repo", branch = "the-pr-branch" }` — doesn't stay up to date with PR.
This PR adds support for specifying a git dependency on the head of a pull request via the existing `rev` setting of git dependencies: `{ git = "the upstream", rev = "refs/pull/9859/head" }`.
Previously this would fail because the `cargo::sources::fetch` function touched in this pull request did not fetch the refspec that we care about. The failures look like:
```console
error: failed to get `mockall` as a dependency of package `testing v0.0.0`
Caused by:
failed to load source for dependency `mockall`
Caused by:
Unable to update https://github.com/asomers/mockall?rev=refs/pull/330/head
Caused by:
revspec 'refs/pull/330/head' not found; class=Reference (4); code=NotFound (-3)
```
If dual purposing `rev` for this is not appealing, I would alternatively propose `{ git = "the upstream", pull-request = "9859" }` which Cargo will interpret using GitHub's ref naming convention as `refs/pull/9859/head`.
Update suggestion message on bad project name error
closes#9876
Error message suggest adding `[bin]` to `Cargo.toml` which should be `[[bin]]` instead.
Improve error message when unable to initialize git index repo
With this - it'll be more obvious which git repo
couldn't be initialized.
Looks like this
```
➜ cargo RUST_BACKTRACE=1 target/debug/cargo build
error: failed to get `anyhow` as a dependency of package `cargo v0.57.0 (/Users/nipunn/src/cargo)`
Caused by:
failed to initialize index git repository (in "/Users/nipunn/.cargo/registry/index/github.com-1ecc6299db9ec823")
Caused by:
failed to parse config file: invalid configuration key (in /Users/nipunn/.config/git/config:1); class=Config (7)
```
Does the best we can with #9854 - since I don't think it can actually be fixed.
Fixes#9854
Stabilize patch-in-config (and prefer config over manifest)
Tracking issue: https://github.com/rust-lang/cargo/issues/9269
---
This stabilizes the `patch-in-config` feature ([unstable entry](https://doc.rust-lang.org/cargo/reference/unstable.html#patch-in-config)) following the discussion in https://github.com/rust-lang/cargo/issues/9269#issuecomment-904913263.
As requested, this PR _also_ changes the precedence behavior such that a `[patch]` for the same dependency in both `.cargo/config.toml` and `Cargo.toml` prefers the patch from the configuration file over the one from the manifest, which matches the behavior of other overlapping configuration options. The corresponding test has also been updated to reflect this change in behavior.
Swap out some outdated repo urls in documentation
I noticed that `rand` and `rustfmt` are no longer located in rust-lang-nursery.
Rather than updating `rand` to github.com/rust-random/rand, I've swapped it out for `regex` in this PR. Some considerations:
- Preference for github.com/rust-lang over github.com/rust-random to reduce the perception of unnecessarily endorsing a project that isn't already endorsed by being in Cargo's org.
- Ruled out `libc` because make-your-own-libcpocalypse is not a fun detour for anyone following along and experimenting with git dependencies.
- Ruled out everything with a -rs suffix (`git2-rs`, `flate2-rs`, `backtrace-rs`, `futures-rs`) out of personal distaste.
- Went for something that has comparable name recognition to rand, i.e. ruled out `hashbrown`.
We could alternatively use dummy URLs like github.com/user/example everywhere but I feel that maintaining this every several years is not a big deal and is worth it for the character of the documentation.
Change `cargo fix --edition` to only fix edition lints.
This changes it so that `cargo fix --edition` will only fix edition lints. The reason for this is that sometimes non-edition lints get in the way, and make suggestions that can cause failures. An example is a user that only ever runs `cargo test` or `cargo check --profile=test` locally, and doesn't realize there are problems with running without `cfg(test)` such as unused warnings.
This works by using `--cap-lints=allow` along with `--force-warn` which takes precedence over `cap-lints`.
This only works on nightly since `--force-warn` is still unstable. I will update this as part of #9800.
Closes#5738
Show desc of well known subcommands (fmt, clippy) in cargo --list
Fixes#8680
An approach to #8680 that shows these in `cargo --list` without showing them directly in the `cargo --help`.
```
➜ cargo git:(desc) target/debug/cargo --list | grep clippy
clippy Checks a package to catch common mistakes and improve your Rust code.
```
Here's what mine looks like visually now:
![image](https://user-images.githubusercontent.com/1300387/131178775-2255ef0d-1993-47dd-bc73-9015394b967c.png)
Fix test not to rely on `cargo` in PATH.
This fixes a test that was trying to execute `cargo` from PATH. This test doesn't work on rust-lang/rust where the rustup installation is removed, and thus there is no `cargo` in PATH.
Improve resolver message to include dependency requirements
Resolves#6199.
Thanks for previous efforts: #5452, #6374, #6665, which are great but somehow outdated, so I tweak them and create this PR. This will also be obsolete if we ship pubgrub-rs with cargo in the future 😃 But before that happens, IMO these changes are still helpful.
---
This PR changes the resolver error message from
216f915c46/tests/testsuite/build.rs (L1104-L1106)
to
0afd40b4de/tests/testsuite/build.rs (L1104-L1106)
Also provide different message for different source kinds, such like:
0afd40b4de/tests/testsuite/build.rs (L2810-L2812)
## TODO?
From https://github.com/rust-lang/cargo/pull/5452#issuecomment-402832200, there shall be at least one task left behind:
> 3. Special case pind by a lock file and not a `"=1.1.2"` in a dependency. Also add a "note: try cargo update" to the end.
In this PR, `validate_links` also faces this issue that a dependency requirement is locked into a precise version `=0.1.0`.
a5f8bc94f5/tests/testsuite/build_script.rs (L1002-L1004)
I am uncertain about how to resolve this. Besides the function`validate_links`, is this problem really a thing that may happen? If not, since `validate_links` only handles old validation logic, it may be ok to drop the commit a5f8bc94f5 and leave it as is.