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.
Due to rendering limits with GitHub's markdown renderer, we're moving
the changelog to the cargo book where it can be statically served under
our control.
This fixes the `standard_lib::shared_std_dependency_rebuild` test while
running on Windows. On my system, `CARGO_MANIFEST_DIR` is a normal
windows-style path (`D:\rust\cargo`) with backslashes. That is not valid
TOML syntax. I don't know why this doesn't fail on CI (maybe CI sets a
unix-style current dir?).
This fixes some warnings that show up on Windows:
```
warning: unused variable: `path`
--> tests\testsuite\registry.rs:3146:24
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^ help: if this is intentional, prefix it with an underscore: `_path`
|
= note: `#[warn(unused_variables)]` on by default
warning: unused variable: `permissions`
--> tests\testsuite\registry.rs:3146:37
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_permissions`
```
### What does this PR try to resolve?
This came up in #13623 to avoid putting tokens into shell history.
### How should we test and review this PR?
The exact approach to deprecation can vary
- Include `<token>` in at least some docs for discovery (most likely the
man page)
- Don't warn yet
etc
I also suspect we could reorganize `cargo help login` but wanted to
decouple that from this change.
### Additional information
There were some changes in the latest nightly which is breaking some
tests:
* https://github.com/rust-lang/rust/pull/133154 updated the wording of a
message. I adjusted the test to be less sensitive to the exact wording.
* https://github.com/rust-lang/rust/pull/119286 added the
`linker-messages` lint which shows the output from the linker. Some of
our tests were passing dummy flags to the linker, which it was
complaining about. This updates it so that it uses real directories.
* This also fixes an incidental issue, where
`build_script_needed_for_host_and_target` was not testing for the
correct command-line flags. These got lost in
https://github.com/rust-lang/cargo/pull/14132.
Nightly recently introduced the `linker-messages` lint which prints any
messages from linkers. These tests were triggering that lint because
they were passing missing directories to the linker. This fixes it by
creating empty directories to pass to the linker.
Note that this lint will be downgraded soon via
https://github.com/rust-lang/rust/pull/136098, but it seemed worthwhile
to fix the underlying problem.
This also fixes a problem where build_script_needed_for_host_and_target
was not testing for the correct command-line flags. These got lost
in https://github.com/rust-lang/cargo/pull/14132.
### What does this PR try to resolve?
In PR #14980, the Ord impl for SourceId was changed, but the comment
wasn’t updated. So it is now incorrect.
This PR updates the comment to match the implementation.
### How should we test and review this PR?
Read the Ord for SourceId code and make sure the updated comment
describes what it does.
### Additional information
None
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker=rust-lld` (which is already present in the
test) is enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
<!--
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.
-->
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker` (which is already present in the test) is
enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
There isn't a good reason to use unsafe code here, and as far as I know
`LazyLock` meets the MSRV of 1.82 as it was added in 1.80. Should have
no change to behavior.
Cargo expands globs when loading workspace members. If the glob happens
to match some non-crate directory, it causes an error that may be tricky
to understand, because it makes Cargo complain that it failed to read a
`Cargo.toml` from a specific directory, but that directory name won't be
listed explicitly anywhere in `Cargo.toml`, so it may seem that Cargo is
trying to read some made-up phantom manifest.
I've made the error messages mention which glob has been used to select
the missing workspace member.
Staged changes don't really need protecting, and `--allow-dirty` is
stronger than `--allow-staged`, so it can imply `--allow-staged` to make
usage of `cargo fix` less verbose.
Closes#14176
