### What does this PR try to resolve?
As part of cargo plumbing commands, we're trying to make lockfiles more
accessible to third-party uses. This change moves the lockfile schemas
to `cargo-util-schemas`, where it is previously under `cargo` and are
relatively hidden.
See also: https://github.com/crate-ci/cargo-plumbing/issues/82
### How to test and review this PR?
Commit by commit to see the changes made. My main concern is performance
as the implementation repeatedly calls `SourceId::from_url` and I'm not
sure if its negligible.
r? @epage
Clarify handling of multiple version requirements of disjoint regions
### What does this PR try to resolve?
Resolves a gap in the existing documentation around the dependency
specification for multiple version requirements.
### How to test and review this PR?
As only an update to the cargo book, review should be straightforward
### What does this PR try to resolve?
Adds ghostty to the list of terminals that support OSC 9;4
This is supported as of Ghostty 1.2.0 (released on September 15, 2025)
https://ghostty.org/docs/install/release-notes/1-2-0#graphical-progress-bars
### How to test and review this PR?
I just compiled cargo, then used the new cargo to try to build the repo
(with another target so it actually compiled)
Ex:
`./target/debug/cargo build --target aarch64-apple-ios`
The progress bar can be seen in the top of the terminal:
<img width="833" height="585" alt="image"
src="https://github.com/user-attachments/assets/494a03fe-c337-4935-9ac3-0b0144f47b2f"
/>
### What does this PR try to resolve?
This PR addresses confusion in the documentation around git sources and
git registries that has been causing frustrating user experiences. The
current documentation is unclear about the purpose of git sources and
doesn't mention that they're not usable for replacing registries,
leading users to mistakenly assume git sources can replace registries
using the git protocol.
Fixes#15971
### How to test and review this PR?
- Documentation build verification: Ensure the markdown renders
correctly and all cross-references work
- Link validation: Verify all new reference links point to existing
documentation sections
- Content accuracy: Confirm technical explanations are correct and align
with Cargo's actual behavior
### What does this PR try to resolve?
The wording for our errors was indirect and things weren't as clear
without more context.
### How to test and review this PR?
### Notes
Example of rustc's versions of these errors:
1
> ```
> error: unclosed frontmatter
> --> $DIR/frontmatter-whitespace-2.rs:1:1
> |
> LL | / ---cargo
> ... |
> LL | |
> | |_^
> |
> note: frontmatter opening here was not closed
> --> $DIR/frontmatter-whitespace-2.rs:1:1
> |
> LL | ---cargo
> | ^^^
> ```
2
> ```
> error: extra characters after frontmatter close are not allowed
> --> $DIR/extra-after-end.rs:2:1
> |
> LL | ---cargo
> | ^^^^^^^^
> ```
3
> ```
> error: frontmatter close does not match the opening
> --> $DIR/mismatch-1.rs:1:1
> |
> LL | ---cargo
> | ^--
> | |
> | _the opening here has 3 dashes...
> | |
> LL | |
> LL | | ----
> | |_---^
> | |
> | ...while the close has 4 dashes
> ```
Within a function in the _Constraints and Heuristics_ section, a
variable `pkg_queue` was used, which does not exist. I replaced it with
similiarly named `dep_queue`, as I believe that is what was meant.
For comparison, the rustc error is:
> error: extra characters after frontmatter close are not allowed
> --> $DIR/extra-after-end.rs:2:1
> |
> LL | ---cargo
> | ^^^^^^^^
Within a function in the _Constraints and Heuristics_ section, a variable `pkg_queue` was used, which does not exist. I replaced it with similiarly named `dep_queue`, as I believe that is what was meant.
### What does this PR try to resolve?
When attempting to substitute a local version of a dependency, since the
`patch` section uses syntax similar to a dependency (and the
documentation even says "The syntax is similar to the `[dependencies]`
section", it's natural to assume that other things from `[dependencies]`
also work, such as `features` or `default-features`. Attempting to use
them produces this warning:
> patch for `crate-name-here` uses the features mechanism.
> default-features and features will not take effect because the patch
dependency does not support this mechanism
The phrasing "the patch dependency does not support this mechanism"
makes it seem at first glance like `patch` just doesn't support this at
all. But the actual problem is that the user needs to move the
`features`/`default-features` keys to an entry in `dependencies`
instead.
Closes#13522
### How to test and review this PR?
This applies the review feedback from #13522 that the author didn't have
a chance to get back to.
### What does this PR try to resolve?
Of the non-ideal error cases mentioned in #15939, this is likely the one
people will hit the most and so important for us to improve.
### How to test and review this PR?
Further iteration can show the opening code fence as well to provide
more context for the error.
### What does this PR try to resolve?
This will complete the name for third-party subcommands, like
`cargo-release`. This does not complete their args
This is part of #14520.
### How to test and review this PR?
### What does this PR try to resolve?
The current wording (from #14839) makes it sound like new Cargo doesn't
care about the `features` entries when in reality Cargo does care still,
the field is just defaulted.
Closes#15408
### How to test and review this PR?
When attempting to substitute a local version of a dependency, since the
`patch` section uses syntax similar to a dependency (and the
documentation even says "The syntax is similar to the `[dependencies]`
section", it's natural to assume that other things from `[dependencies]`
also work, such as `features` or `default-features`. Attempting to use
them produces this warning:
> patch for `crate-name-here` uses the features mechanism.
> default-features and features will not take effect because the patch dependency does not support this mechanism
The phrasing "the patch dependency does not support this mechanism"
makes it seem at first glance like `patch` just doesn't support this at
all. But the actual problem is that the user needs to move the
`features`/`default-features` keys to an entry in `dependencies`
instead.
Modify the message, to make this more obvious.
Modify the corresponding warning for `replace` as well.
Update tests accordingly.
### What does this PR try to resolve?
This changes the future-incompat message to be reported in a single
`Report`. The primary motivation is to cleanup the output compared to
taking the existing note's and aligning all content with the first line
which is what would happen otherwise in #15917.
In preparation for this, the message was cleaned up and made more like
what a rustc message might look like.
### How to test and review this PR?
