This comes with improved redacting on mismatches which will provide
more focused assertions and there will be less need for intervention on
snapshot updates.
This also gives more flexibility with placeholders
We allowed `[badges]` to inherit from `[workspace.package.badges]`
This was a bug:
- This was not specified in the RFC
- We did not document this
- Even if someone were to try to guess to use this, it is inconsistent
with how inheritance works because this should inherit from
`workspace.badges` instead of `workspace.package.badges`
While keeping in mind that `[badges]` is effectively deprecated.
In that context, I think its safe to break support for this without a
transition period.
Fixes#13643
Fix warning suppression for config.toml vs config compat symlinks
### What does this PR try to resolve?
Background: the cargo config file is being renamed from `.cargo/config` to `.cargo/config.toml`. There's code in new cargo to look for both files (for compatibility), to issue a warning when onliy the old filename is found, and also to issue a warning if both files are found. The warning suggests making a symlink if compatibility with old cargo is wanted.
An attempt was made to detect when both the old and new files exists, but one is a symlink to the other, but as reported in #13667, this code is not effective. (It would work only if the symlink had the precise absolute pathname that cargo has decided to use for the lookup, which would be an unnatural way to make the link.)
Logically, the warning should appear when both files exist *but are different*. That is the anomalous situation that will generate confusing behaviour. By "different" we ought to mean "aren't the very same file".
That's what this MR implements, where possible. On Unix, we use the information from stat(2). That's not available on other platforms; on those, we arrange to also tolerate a symlink referring to precisely `config.toml` as a relative pathname, which is also fine, since by definition the target is then in the same directrory as `config`.
Fixes#13667.
### How should we test and review this PR?
I have interleaved the new tests with the commits that support them. In each case, a functional commit is followed by a test which fails just beforehand.
(This can be observed by experimentally reordering the branch.)
I have also done ad-hoc testing.
### Additional information
I'm making the assumption that a symlink containing a relative path does something sane on Windows. This assumption may be unwarranted. If so, "Handle `config` -> `config.toml` (without full path)" needs to be dropped, and the test case needs to be `#[cfg(unix)]`.
But also, in this case, we should probably put some warnings in the stdlib docs!
This is 100% reliable on Unix, and better on Windows.
(In this commit I avoid reindenting things to make review easier; the
formatting will be fixed in the next commit.)
Fixes#13667
gate some libc usages under cfg(unix), drop os_info features
Places few `libc` usages under `cfg(unix)`. That didn't remove it from tree, but still looks cleaner.
Drop features from os_info crate, as serde support currently unused.
chore(deps): update rust crate opener to 0.7.0
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [opener](https://togithub.com/Seeker14491/opener) | workspace.dependencies | minor | `0.6.1` -> `0.7.0` |
---
### Release Notes
<details>
<summary>Seeker14491/opener (opener)</summary>
### [`v0.7.0`](https://togithub.com/Seeker14491/opener/blob/HEAD/CHANGELOG.md#070---2024-03-22)
[Compare Source](https://togithub.com/Seeker14491/opener/compare/v0.6.1...v0.7.0)
##### Added
- "dbus-vendored" feature, which is enabled by default to match current behavior. This just forwards to the `dbus` crate's "vendored" feature. Disable it to link dynamically to dbus instead of statically.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNjkuMiIsInVwZGF0ZWRJblZlciI6IjM3LjI2OS4yIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIn0=-->
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.
feat(tree): Control `--charset` via auto-detecting config value
### What does this PR try to resolve?
This tries to generalize `cargo tree --charset` so any part of cargo's output can use it. For example,
- `cargo search` could use this for fancier tables
- `cargo add` could use this for fancier feature lists
- #12235 could use this for fancy rendering like miette does (CC `@Muscraft` )
- Progress bars could use fancier characters <-- this is what I'm personally working towards
This builds on the idea from #12889 that we can use fancier terminal features so long as we have good auto-detection and provide users an escape hatch until the auto-detection is improved or in case they disagree.
As a side benefit
- `cargo tree` will auto-detect when the prior default of `--charset utf8` is a good choice
- Users can control `cargo tree --charset` via `.cargo/config.toml`
### How should we test and review this PR?
This is gradually introduced through the individual commits.
### Additional information
chore: update pulldown-cmark to 0.10.0
### What does this PR try to resolve?
Update a dependency and address its breaking changes.
`pulldown-cmark: 0.9.3 -> 0.10.0`
Fixes: https://github.com/rust-lang/cargo/issues/13509
### How should we test and review this PR?
The `.md` and `.1` docs are updated as part of this commit, you can see there that nothing changes except for removal of some trailing whitespace.
