### What does this PR try to resolve?
Some very small simplifications made while poking around the resolver. I
was trying to understand when we would end up hitting a `continue` in
the code. The easiest way was to run the tests with a panic instead.
Turns out I was right, we cannot/(can no longer) hit that code path.
Which allowed us to simplify some other surrounding code.
### How should we test and review this PR?
All tests pass on each commit.
### Additional information
### What does this PR try to resolve?
Fixes https://github.com/rust-lang/cargo/issues/12978
currently, if `--package `and `--workspace` passe in the same time, the
`--package` will be ignore even the package doesnt exist in the
workspace, this PR regards this behavior as an error
### How should we test and review this PR?
one commit add test, one commit fixes the issue.
### Additional information
This adds a check to fix an issue where the cache tracking
synchronization was breaking on unexpected files like macOS's
`.DS_Store` (see commit for details).
Fixes https://github.com/rust-lang/cargo/issues/15145
This makes the cache tracking synchronization code resilient to
unexpected files in the cache directory. Previously the code was
assuming that all entries in paths like `registry/index/*` are
directories. However, in circumstances like opening the directories in
macOS's finder, that can create files called `.DS_Store`. This caused it
to fail to scan within that path, since it isn't a directory.
This could in theory be made stricter, such as expecting directories to
have a particular pattern for its name. However, it seems like we never
enacted restrictions on what names are used for the git directories, so
it wouldn't work very well for that. Though that is something we could
consider in the future.
### What does this PR try to resolve?
close https://github.com/rust-lang/cargo/issues/14831
In this PR, we added the `cargo pkgid` support for the cargo-script.
For the package itself:
```console
cargo pkgid --manifest-path foo.rs
path+file:///my-project/foo.rs/foo#0.86.0
```
For its dependence:
```console
cargo pkgid --manifest-path foo.rs -p sqlx
registry+https://github.com/rust-lang/crates.io-index#sqlx@0.7.4
```
### How should we test and review this PR?
I have updated the unit tests and also added more test cases for it.
### Additional information
None
### What does this PR try to resolve?
When you typo a feature name on the CLI, the error message isn't very
helpful. Concretely, I was testing a PR which adds a feature called
`cosmic_text` to enable a `cosmic-text` dependency, and got a correct
but unhelpful error message:
```rust
error: Package `scenes v0.0.0 ([ELIDED]/linebender/vello/examples/scenes)` does not have feature `cosmic-text`. It has an optional dependency with that name, but that dependency uses the "dep:" syntax in the features table, so it does not have an implicit feature with that name.
```
I had to dig into the Cargo.lock file to find out how to fix this.
### How should we test and review this PR?
Observe the new test cases
The left-aligned error message is there to
workaround rustfmt refusing to format files
which contain string literals which are too
wide. I have not found a consistent way to
fix this behaviour, but left-aligning does
resolve it in this case. I believe that this
should have an explanatory comment, but code
review determined that to be "noise" and so
I removed it.
### What does this PR try to resolve?
This is an attempt at moving Cargo closer to [rustc's diagnostic
guide](https://rustc-dev-guide.rust-lang.org/diagnostics.html#suggestion-style-guide)
(clap already did this)
> Suggestions should not be a question. In particular, language like
"did you mean" should be avoided. Sometimes, it's unclear why a
particular suggestion is being made. In these cases, it's better to be
upfront about what the suggestion is.
>
> Compare "did you mean: Foo" vs. "there is a struct with a similar
name: Foo".
### How should we test and review this PR?
### Additional information
I did leave behind three "did you mean"s as I was a little less sure in
how to handle them
This removes the original changelog now that it is located in the cargo
book.
This places a notice in the original location that it has moved to a new
place. There are a few other alternatives we could consider:
* Keep the headings but replace the content with a link. This would make
it a little easier for someone to jump to the exact position in the new
page. However, it looks a little messy. Each section could be something
like:
> This content has moved to
[CHANGELOG.md#186-2025-04-03](https://doc.rust-lang.org/cargo/nightly/CHANGELOG.md#186-2025-04-03)
* Keep the content, with a notice at the top that the page is no longer
being updated. I was a little uncomfortable with this, since I wasn't
sure people would see the notice, it duplicates some content, and still
leaves the potential problems of GitHub not rendering the page. If we
cut some content, it ensures the page still renders reliably.
* As a variant, we could delete the content but keep the last 1 or 2
releases since those are probably what people will be looking for.
Opening as draft until https://github.com/rust-lang/cargo/pull/15119 is
published on nightly.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
We are progressively moving the windows CI from windows 2022 to windows
2025 because we found windows 2025 more stable.
In https://github.com/rust-lang/rust/pull/136478 a cargo test failed and
this might solve the issue. See
[this](https://github.com/rust-lang/rust/pull/136478#issuecomment-2631307932)
comment. What do you think?
If you have a better way of solving this, let me know 👍
Hey there,
While reading the documentation, I noticed that the word 'considered'
was written two times. So I removed one.
Thank you!
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your
PR.
With a smooth review process, a pull request usually gets reviewed
quicker.
If you don't know how to write and run your tests, please read the
guide:
https://doc.crates.io/contrib/tests
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
Authentication errors shouldn't unconditionally recommend running `cargo
login`, because alternative registries configured to use custom
credential providers won't use the token obtained by `cargo login`.
### What does this PR try to resolve?
This includes `CARGO_COMPLETE=` and `CARGO_COMPLETE=0` to disable
completions. I'm wanting access to this for my bash script that runs
Cargo out of the `target/debug` without the outer cargo doing the
completions
### How should we test and review this PR?
### Additional information
This moves cargo's changelog to the cargo book. We're bumping into
rendering limits on GitHub's side, so we're moving the changelog to the
cargo book where it can be statically served under our control.
This PR is structured in such a way that the original CHANGELOG.md file
is kept in place (and history is preserved in the new copy). The intent
is to wait until this PR makes it to the nightly channel, and then open
a new PR that will delete the original. That will look something like
5ce7947693.
This makes use of a new mdbook feature in order to exclude the changelog
chapter from the search index. It completely swamps the search results,
so I think it is best to just exclude it.
We'll need to coordinate with the release team so that future release
notes link directly to the cargo book instead of GitHub.
