This is the only error we do this for and we have the context for what
manifest we are parsing.
By removing this, it makes it easier to adjust lifetimes in the short
term.
test: Add asserts to catch BorrowMutError's
### What does this PR try to resolve?
This intentionally borrows from `RefCell`s before conditional code to try to prevent regressions like #13646 without exhaustively covering every case that could hit these `BorrowMutError`s with complicated tests.
### How should we test and review this PR?
I tested this by ensuring the registry code path panicked before rebasing on top of #13647.
Once I rebased, the panic went away.
### Additional information
Split off from #13649 to try to avoid appveyor
This intentionally borrows from `RefCell`s before conditional code
to try to prevent regressions like #13646 without exhaustively
covering every case that could hit these `BorrowMutError`s with
complicated tests.
I tested this by ensuring the registry code path panicked before
rebasing on top of #13647.
Once I rebased, the panic went away.
Co-authored-by: Ed Page <eopage@gmail.com>
Publish test crates
### What does this PR try to resolve?
This is an attempt to close#10147. In short, publish the `cargo-test-(macro|support)` crates to crates.io.
Main parts:
* Updating the concerned manifests to make the packages publishable.
* Adding them to `publish.py`: not sure if you want this to be done. I put them after all other packages and in reverse-dependency order to ensure things will work the best, hopefully.
* Updating the contribution documentation to reflect the change. I didn't see any other place where the crates' publication was mentioned.
### How should we test and review this PR?
Sadly, the effective testing could not be done by me as it would require publishing the crates, which would block future publications by Cargo team members and therefore render the whole point of this impossible or cumbersome. Hopefully, the PR is small and readable enough that mistakes can be seen easily. The real testing would need to be done manually by some team member either before by checking the source branch out or after merging.
The only testing I was able to perform was to run `cargo publish --dry-run -p cargo-test-(macro|support)`. The first worked just fine. The second failed on the `crates-io` package not being available on crates.io in version `0.40.0`. However, the package is in this version in the current sources. I therefore suspect that a run of `publish.py` should work since the packages have been added there after `crates-io`.
### Additional information
This is very much tentative and open to discussion. I tried my best to update things as I understood them. Please correct me on anything I would have done wrong or simply not thought of.
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.
