### 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?
### What does this PR try to resolve?
Our options are:
- Not offer these completions
- Hide them
- De-prioritize them
Since someone could be using `--package`, I felt de-prioritizing would
give the best experience.
This is a follow up to #15309
### How to test and review this PR?
Along the way, I made things more consistent across completions
### What does this PR try to resolve?
This fills a whole in our coverage of dependency resolution by
specifying how a `Cargo.lock` impacts it.
### How to test and review this PR?
I put it after version numbers and version requirements as it builds on
those two topics.
Unsure whether this fully resolves the concern from #15587 of users
coming from other ecosystems that have been burned by library lockfiles
affecting them to know that they won't be subject to that.
### What does this PR try to resolve?
I occasionally open PRs in my fork to test CI for work in progress
changes. (Trying to avoid spamming notifications to the t-cargo members)
The `check-version-bump` job [makes
assumptions](https://github.com/rust-lang/cargo/blob/master/crates/xtask-bump-check/src/xtask.rs#L326)
that the fork has an up to date list of release tags.
My fork (and I am guessing most others) does not contain the release
tags so this CI job fails, which is a minor papercut.
My solution is to only run `check-version-bump` in PRs to
`rust-lang/cargo` and skip in forks.
### How to test and review this PR?
* Verify that the CI job runs in this PR.
* I checked that job was skipped in my fork in
https://github.com/ranger-ross/cargo/actions/runs/17678491699/job/50246604369?pr=8
Inspired by https://github.com/rust-lang/cargo/pull/15138 , this
eliminates the last three instances.
Also rephrase a comment that implied the use of "did you mean"
suggestions. Fix an adjacent typo in that comment as well.
I put it after version numbers and version requirements as it builds on
those two topics.
Unsure whether this fully resolves the concern from #15587 of users
coming from other ecosystems that have been burned by library lockfiles
affecting them to know that they won't be subject to that.
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
Our options are:
- Not offer these completions
- Hide them
- De-prioritize them
Since someone could be using `--package`, I felt de-prioritizing would
give the best experience.
