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
In general, Cargo merges lists in configuration by concatenating them.
However, sometimes the lists don't make sense for merging, such as a
program and its arguments. We had the `UnmergedStringList` type that
handled this case for merging environment variables, but it did not work
for multiple configs.
* Removes the `UnmergedStringList` type, which only worked for
preventing merging of environment variables with configuration.
* Adds a new function `is_nonmergable_list` which hard-codes which
configuration keys contain lists that should not be merged.
Fixes#14906
Hey there,
As mentioned in this
[issue](https://github.com/rust-lang/cargo/issues/14520), I worked on
the functionality of autocompleting the user-defined aliases and I moved
the code of user-defined aliases into a separate function by defining
two parameters. The first one is global context or gctx and the second
one is the commands that can be called in the list_commands function.
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.
-->
Hey there,
I just moved the functionality of the third-party subcommand from the
[list_commands](https://github.com/rust-lang/cargo/blob/master/src/bin/cargo/main.rs#L184)
function to another new function by the name of third_party_subcommand
name and called that function in the list_commands function.
From my understanding regarding the third-party subcommand from this
[tracking issue](https://github.com/rust-lang/cargo/issues/14520),
following points should be performed.
- The code that gathers third-party subcommands in list_commands should
be moved into a separate function that I did.
- This new function will be called both by list_commands and the code
for adding subcommand completions. Although I called the function in the
list_commands but didn't understand the second point.
- Test the change that I made in the first place but it gave me this
error:
<!--
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.
-->
### What does this PR try to resolve?
Fixes a wrong concatenation in macro, and one wrong field name.
### How should we test and review this PR?
`cargo doc --document-private-items --no-deps --open`
### What does this PR try to resolve?
I didn't extend this to multiple packages restricted to specific
registries.
It seems less likely to be a problem and more complex to gather and
report.
This was inspired by feedback left at #10948
### How should we test and review this PR?
### Additional information
I didn't extend this to multiple packages restricted to specific
registries.
It seems less likely to be a problem and more complex to gather and
report.
This was inspired by feedback left at #10948
### What does this PR try to resolve?
This was overlooked in #14815.
### How should we test and review this PR?
```
cargo build
target/debug/cargo help package
# and read the manpage
```
### What does this PR try to resolve?
This was left as a future-possibility in
[RFC
#3052](https://rust-lang.github.io/rfcs/3052-optional-authors-field.html).
Without a clear role for this field within Cargo/crates.io,
there seems little reason to actively support it (e.g. #14949, #15027),
including working through feature requests.
I see the potential for having some fields with more specific roles
(where to go for support, where to go for disclosing vulnerabilities,
etc)
but even these run into the mutable data problem of `authors`.
Users can always manage metadata for their own purposes through
`package.metadata`.
The RFC called out clap as an example of something that uses this.
Clap no longer does by default but users can opt-in through a
`help_template`.
For now, this notes the status in the documentation.
When we have[user control over Cargo lint (#12235)
(and figure out namespacing with lints that overlap with Rust),
we can give a warning on this.
Based on feedback from users, we can evaluate removing this field in a
future edition.
This is as discussed in a recent Cargo team meeting
### How should we test and review this PR?
### Additional information
We may want to consider doing similar for `badges`
### What does this PR try to resolve?
Restore to the behavior prior to
30d11ce1d9f06907d1e707c4fe379ebf57305a5e
Also extend `build-std-features` to support comma-separated list.
Fixes#15064
### How should we test and review this PR?
A test has been added.
This fixes a problem introduced with git 2.48.0 where the benchsuite
would fail to run. The problem is that 2.48 changed the behavior so that
HEAD would get changed to follow the remote. crates.io-index's default
branch is "main". The benchsuite uses git to initialize the bare repo
with a HEAD of "refs/heads/master" (the default of
`init.defaultBranch`). Older versions of git would leave HEAD untouched,
but newer versions update it to "refs/heads/main" after fetching to
match the remote. This causes cargo to try to clone a branch called
"main" which is empty.
The solution here is to just force HEAD to be main, and use that as the
branch for our time-travelling snapshot.
Tested with git 2.47.0 and 2.48.1. Test is roughly:
```
rm -rf target/tmp/bench ; cargo test -p benchsuite --all-targets -- cargo && cargo test -p benchsuite --all-targets -- cargo`
```
(Run it twice to verify it can do an incremental fetch.)
