- `set_require_newline_after_table` was added in #2680 back in 2016
- `set_allow_duplicate_after_longer_table` was added in #6761 in 2019
Several years later, this PR is turning these warnings into errors.
The function and documentation was kept so we can add additional hacks
in the future, like if we switch TOML parsers.
Revert "When a dependency does not have a version, git or path, fails directly"
Reverts rust-lang/cargo#9686
We discussed, and felt like this change wasn't all that important, and a few people have mentioned that it caused problems for them.
Closes#9885
Fix warnings when documenting with `--document-private-items`
- Use hyperlinks for URLs
- Fix broken intra-doc links
This doesn't fix the following warning, since I wasn't sure what change
was appropriate:
```
warning: public documentation for `rustc_process` links to private item `self::core::compiler::Context::primary_packages`
--> src/cargo/core/compiler/compilation.rs:164:22
|
164 | /// flag), see [`crate::core::compiler::Context::primary_packages`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this item is private
|
= note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
= note: this link resolves only because you passed `--document-private-items`, but will break without
```
To avoid noise, this doesn't add an `allow` either.
Improve "wrong output" error.
The error message for an improperly formatted build script output was a bit abrupt and unhelpful. This adds some more details to the error message.
Fix warnings from better precision of `dead_code` lint
The lint now ignores derived `Clone` and `Debug` implementations, as of
PR rust-lang/rust#85200, which landed a couple of days ago.
I sprinkled `#[allow(dead_code)]` in a few places; the fields are not
expected to be read since they are just part of a very specific test.
The lint now ignores derived `Clone` and `Debug` implementations, as of
PR rust-lang/rust#85200, which landed a couple of days ago.
I sprinkled `#[allow(dead_code)]` in a few places; the fields are not
expected to be read since they are just part of a very specific test.
- Use hyperlinks for URLs
- Fix broken intra-doc links
This doesn't fix the following warning, since I wasn't sure what change
was appropriate:
```
warning: public documentation for `rustc_process` links to private item `self::core::compiler::Context::primary_packages`
--> src/cargo/core/compiler/compilation.rs:164:22
|
164 | /// flag), see [`crate::core::compiler::Context::primary_packages`].
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this item is private
|
= note: `#[warn(rustdoc::private_intra_doc_links)]` on by default
= note: this link resolves only because you passed `--document-private-items`, but will break without
```
To avoid noise, this doesn't add an `allow` either.
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.
