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.)
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.
We may want to consider doing similar for `badges`
Initially discussed in
https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/env!.2Foption_env!.20are.20tracked.2C.20can.20documentation.20be.20improved.3F/near/491793318
### What does this PR try to resolve?
There is no documentation that I can find which indicates that cargo
will rebuild for changes in the variables used in `env!` macros.
Because this was not always the case, when searching for information on
this, the main result indicates otherwise
https://users.rust-lang.org/t/should-env-cause-rebuild-is-env-var-changes/18013.
Users misled by this may turn to `rerun-if-changed-env` in a build
script to trigger rebuilds, so this documentation is a useful place to
catch users and indicate that it isn't needed for `env!` macros.
### How should we test and review this PR?
I'm not sure how to test the new relative link but I matched it to the
existing `[env-macro]: ../../std/macro.env.html`.
My main concern when writing this was whether it was clear that this
applies to `env!` macro usage within the main code of the crate and not
just in `build.rs`.
### What does this PR try to resolve?
This revives #14962. See benchmark chart in
<https://github.com/rust-lang/cargo/pull/14962#issuecomment-2555318312>.
#14962 was closed because we found more bugs in `cargo package`, and
#14962 could potentially make them even harder to fix. Two of them have
been fixed so this is good to ship IMO with its own good.
---
An improvement https://github.com/rust-lang/cargo/issues/14955.
`check_repo_state` checks the entire git repo status. This is usually
fine if you have only a few packages in a workspace.
For huge monorepos, it may hit performance issues.
For example,
on awslabs/aws-sdk-rust@2cbd34d
the workspace has roughly 434 members to publish.
`git ls-files` reported us 204379 files in this Git repository. That
means git may need to check status of all files 434 times. That would be
`204379 * 434 = 88,700,486` checks!
Moreover, the current algorithm is finding the intersection of
`PathSource::list_files` and `git status`.
It is an `O(n^2)` check.
Let's assume files are evenly distributed into each package, so roughly
470 files per package.
If we're unlucky to have some dirty files, say 100 files. We will have
to do `470 * 100 = 47,000` times of path comparisons.
Even worse, because we `git status` everything in the repo, we'll have
to it for all members,
even when those dirty files are not part of the current package in
question. So it becomes `470 * 100 * 434 = 20,398,000`!
#### Solution
Instead of comparing with the status of the entire repository, this
patch use the magic pathspec[1] to tell git only reports paths that
match a certain path prefix.
This wouldn't help the `O(n^2)` algorithm,
but at least it won't check dirty files outside the current package.
Also, we don't `git status` against entire git worktree/index anymore.
[1]:
https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec
### How should we test and review this PR?
Run this command against
awslabs/aws-sdk-rust@2cbd34db53,
and see if it is getting better.
```
CARGO_LOG_PROFILE=1 cargor package --no-verify --offline --allow-dirty -p aws-sdk-accessanalyzer -p aws-sdk-apigateway
```
I've verified checksums of `.crate` files generated from master
(d85d76199f89d7a312f308f6e37fc40f70508923) and this commit
(3dabdcdd20d6382e7efa2c01833efa20944f3a79). They are the same.
### Additional information
There are some other alternatives, like making `PathSource::list_files`
additionally reports dirty files. While we already have rooms to do it,
this approach should be the most straightforward one at this moment.
Some other approaches like
* Switch to gitoxide (I tried and it didn't as good as expected. Maybe I
did something wrong).
* A flag `--no-vcs` to skip vcs at all
* Improve the `O(n^2)` algorithm
### What does this PR try to resolve?
I was reading the docs to see how to specify a version to use from a git
dependency, and came across this section and got really confused as I
did not know what `N.B.` meant so the following did not read well for
me: `N.B. that if ...`. I had to look it up and then realized that I had
wasted time that did not need to be wasted. Thus this PR aims to prevent
the time of future readers from being wasted.
### How should we test and review this PR?
Try to read aloud the old version and the new one, as well as the given
alternatives to see which would make most sense to the largest number of
people.
### Additional information
A simple fix would be to just remove "that" as this reads better: `N.B.
if a version doesn't match, Cargo will fail to compile!`
#### Other variations
* `Note that if a version doesn't match, Cargo will fail to compile!`
- might be confused as `Notice that if a version doesn't match, Cargo
will fail to compile!`
* Move the comment out to a reworded sentence right below the code block
and perhaps also link to the [`The role of the version
key`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#the-role-of-the-version-key)
section above which clearly states:
> The version key does not affect which commit is used when Cargo
retrieves the git dependency, but Cargo checks the version information
in the dependency’s Cargo.toml file against the version key and raises
an error if the check fails.
Fixes#15048
<!--
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.
-->
<!--
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#13712
Adds a warning if there is an error updating the index cache.
It also attempts to avoid warning spam as requested in [this
comment](https://github.com/rust-lang/cargo/issues/13712#issuecomment-2514991597)
Below is an example output
```
Updating crates.io index
warning: failed to write cache, path: /home/ross/.cargo/registry/index/index.crates.io-1949cf8c6b5b557f/.cache/ba/se/base64, error: Permission denied (os error 13)
Compiling serde v1.0.217
Compiling r-efi v5.2.0
Compiling base64 v0.22.1
Compiling cargo-13712 v0.1.0 (/home/ross/projects/cargo-13712)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.20s
```
### How should we test and review this PR?
I tested this on my machine by manually changing the owner/permission of
the index files
```sh
sudo chown root ~/.cargo/registry/index/.../.cache/r-
sudo chmod 700 ~/.cargo/registry/index/.../.cache/r-
# in a project that uses the `r-efi` crate
cargo build
```
I wasn't quiet sure about the best way to add a test to the testsuite
for this. 😅
If there is good way to create a test for this lmk
"identity" `.into()` calls where the base's type isn't changed is a
future compatibility foot-gun (like the issue we had with `time` a few
months ago) as new `impl Into` blocks can cause previously compiling
code to start failing. I don't foresee these ones in particular causing
problems anytime soon, but I noticed them and might as well clean them
up as a drive-by.
