Do not strip debuginfo by default for MSVC
This PR disables the logic which enables debuginfo stripping by default in release mode (https://github.com/rust-lang/cargo/pull/13257) for MSVC, since it causes problems there (https://github.com/rust-lang/rust/issues/122857).
I'm not sure if this is the correct way to gate the logic on a specific target triple.
The root of the issue is that `-Cstrip=debuginfo` currently behaves like `-Cstrip=symbols` on MSVC, which causes the original optimization to break backtraces on Windows. Ultimately, this should probably be fixed in `rustc`, but that might take some further design work, therefore a faster solution would be to just special case this in Cargo for now, and remove the special case later, once it gets fixed on the `rustc` side.
Related issue: https://github.com/rust-lang/rust/issues/122857
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.
