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
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.
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.
-->
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.
### 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
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
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?
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 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`
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`
### 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
