Fix doc collision for lib/bin with a dash in the inferred name.
This fixes an issue where `cargo doc` would report a collision if the project has a `-` in the name, and both a lib and bin. As a consequence of the change in #12783, the target name for the library no longer has a `-`. The code that checks for the lib/bin doc collision was only checking if the target names were equal, which is no longer the case after #12783. The solution here is to use the `crate_name` and not the target name, which has the appropriate `_` translation done. This is the more correct method to use, even before #12783, because rustdoc uses crate names, not target names (and thus even documenting bins have their filenames converted to underscores).
Fixes#13628
refactor: Make lint names snake_case
When working on #13621, I somehow missed that lint names should be `snake_case` according to the [`rustc-dev-guide`](https://rustc-dev-guide.rust-lang.org/diagnostics.html#lint-naming) as well as [`RFC #344`](https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints).
This PR renames:
- `implicit-features` => `implicit_featires`
- `rust-2024-compatibility` => `rust_2024_compatibility`.
<hr>
Note: We should probably have some tooling to enforce this, but I was unsure if it belonged to this PR or another one. One solution would be to use a macro to create the `const LINT_NAME: Lint = {...}`, where `LINT_NAME` would be the `ident` as well as the `name: &'static str` and then have a method on `Lint` to make it lowercase as needed. This is what `rustc` does, and it could work well here. It would ensure snake case as `const` names need to be [`SCREAMING_SNAKE_CASE`](https://rust-lang.github.io/rfcs/0430-finalizing-naming-conventions.html#general-naming-conventions), or a warning is shown.
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>
