Use `gitoxide` for `list_files_git`
Related to #10150.
### Tasks
* [x] update `gix` to v0.60
* [x] assure this is tested (currently only git-tests run with `git2` and `gitoxide`)
* [x] allow `list_files_git` to use `gitoxide` if it is enabled as feature.
* [x] use dirwalk iterator
* [x] use new release of `gix` with necessary updates
### Review Notes
As this PR has come a long way, I decided to keep a few of the steps leading up to the final state, showing the PR's evolution in the hope it helps the review.
* Would it be better to simply use `gitoxide` for this without a switch? I don't think
it will cause more trouble than `git2`, and if there is an issue I will fix it with priority.
* In one test, the walk resolves a symlink to a submodule to individual files, including the `.git/*` folder contained in the submodule which is ignored by the walk, i.e. `submodule/*` does not contain it, but `submodule-link/*` does. This is fixed in the gitoxide version, and the `git2` version.
* I noticed that symlinks are resolved for packaging *and* are allowed to point to anywhere, even outside of package root. I left it, but felt that maybe this should be reconsidered.
### Remarks
* I love the test-suite! It's incredibly exhaustive to the point where it uncovers shortcomings in `gitoxide`, which I greatly appreciate.
* I also love `git2` as it's API for many things leads to pretty idiomatic code, and sometimes I really have to work to match it. The example here is the initial `dirwalk()` method which requires a delegate as it doesn't just collect into a `Vec` like `git2` does (for good reason). Turning that into an iterator via `dirwalk_iter()` makes it far more usable, and will definitely be good for performance as the dirwalk work is offloaded into its own thread.
fix: Warn on -Zlints
When the `[lints]` table was stabilized in #12648, it appears that making `-Zlints` into a warning when specified was missed, this PR fixes that.
feat: Add a basic linting system
This PR adds a basic linting system, the first step towards [User control over cargo warnings](https://github.com/rust-lang/cargo/issues/12235). To demonstrate the system, a lint for #12826 is added. It supports controlling cargo lints via the `[lints.cargo]` table. Lints can be controlled either by a group or individually.
This is meant to lay down some fundamental infrastructure for the whole linting system and is not meant to be fully featured. Over time, features will be added that will help us reach a much more solid state.
Top-level pathspecs are needed to assure they are not affected by
the CWD. The trailing `/` in `'target` is needed to assure excluded
items are in a folder, and that only entries in that folder are extracted
from the index.
refactor(testsuite): Rename lints to lints_table
In preparation for a linting system for cargo, we need a place to put the tests for new lints. Since they would be UI tests, it would make sense to place them in `tests/testsuite/lints/<lint name>`, but tests for `[lints]` are in `tests/testsuite/lints.rs`. To get around this, I am renaming `lints.rs` to `lints_table.rs` so they do not get confused.
Fix debuginfo strip when using `--target`
This fixes an issue where automatic `strip` of debuginfo added in https://github.com/rust-lang/cargo/pull/13257 wasn't working when the `--target` flag was used.
The problem is that the adjustment code was only running in the optimization pass that is done when `--target` is *not* specified.
The solution is to just always run the unit graph rebuild. I believe it should be safe to do so, since the adjustments it makes should be conditional on just the scenarios that matter when `--target` is not specified. The downside is that this might be a small performance hit when `--target` is used. Trying to avoid that I think would be quite challenging.
Fixes#13617
Fix publish script due to crates.io CDN change
Now that crates.io goes directly to the CDN, this has changed the HTTP response code when a crate is not found (from 404 to 403). This updates the publish script to handle more error codes to assume something isn't published. This also updates it to go directly to the endpoint instead of through the crates.io redirect.
feat: Report some dependency changes on any command
### What does this PR try to resolve?
The goal is to help users be informed when they are held back by either MSRV or semver.
Fixes#13539
### How should we test and review this PR?
### Additional information
refactor(toml): Expose surce/spans for VirtualManifests
### What does this PR try to resolve?
This is a follow up to #13593, expanding support from `Manifest` to `VirtualManifest` as well.
This also does other clean up along the way in preparation for making a more explicit `resolve_toml` phase.
### How should we test and review this PR?
### Additional information
cargo/init: avoid target.name assignments if possible
Make `cargo init` skip `target.name` assignments if the default value is suitable.
Currently, all paths of `cargo init` will set target-names to the package-name, ensuring that a suitable target-name is set. This is required for all targets but libraries. Unfortunately, library-names have more restrictions than other targets. For example, creating a library with dashes will lead to errors:
mkdir foo-bar
cd foo-bar
touch foo-bar.rs
cargo init --lib
Fortunately, target-names for libraries are inferred from the package-name. Hence, by omitting the target-name, a valid configuration will be produced.
Instead of adjusting `SourceFileInformation::target_name` to use `Option<String>`, this commit strips the field completely, since all callers set it to the package-name.
Fixes: #11259
chore: Fix minor grammar nit in command-line help
This change fixes a *very* minor grammar mistake. "Require" used in this way is
typically followed by the infinitive. In addition, since "up-to-date" is used
an adjective now it should be hyphenated.
See https://www.merriam-webster.com/dictionary/up-to-date
### Testing
I have run `cargo test` with `CFG_DISABLE_CROSS_TESTS=1` as well as `cargo
build-man` to regenerate the man pages.
Fixes#13601.
Make `cargo init` skip `target.name` assignments if the default value is
suitable.
Currently, all paths of `cargo init` will set target-names to the
package-name, ensuring that a suitable target-name is set. This is
required for all targets but libraries. Unfortunately, library-names
have more restrictions than other targets. For example, creating a
library with dashes will lead to errors:
mkdir foo-bar
cd foo-bar
touch foo-bar.rs
cargo init --lib
Fortunately, target-names for libraries are inferred from the
package-name. Hence, by omitting the target-name, a valid configuration
will be produced.
Instead of adjusting `SourceFileInformation::target_name` to use
`Option<String>`, this commit strips the field completely, since all
callers set it to the package-name.
Signed-off-by: David Rheinsberg <david@readahead.eu>
With a traditional walk, `.git` will be picked up, and so will be
ignored directories. This commit also doesn't give submodules special
treatment - instead it just tries to open directories as repositories,
or walks them if that fails.
cargo: prevent dashes in lib.name
The TOML parser of Cargo currently refuses `lib.name` entries that contain dashes. Unfortunately, it uses the package-name as default if no explicit `lib.name` entry is specified. This package-name, however, can contain dashes.
Cargo documentation states that the package name is converted first, yet this was never implemented by the code-base.
Fix this inconsistency and convert the package name to a suitable crate-name first.
This fixes#12780. It is an alternative to #12640.
