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.
fix 13773 - 'cargo build' fails when list_files() with gix is triggered
Fixes#13773.
### Tasks
* [x] reproduce issue with new test-case
* [x] update [fixed `gix-dir`](https://github.com/rust-lang/cargo/pull/13777) in Cargo.lock to turn test green
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
This uses a new feature from snapbox that let's us render terminal
styling in SVG files. This let's us see / visualize ANSI escape codes,
including in github's UI (will render images, including side-by-side
images for diffs).
We already do this so long as the argument doesn't look like a
`cargo test` argument (e.g. `--show-output`)
but `--ignored` looks like `--ignore-rust-version` do the the suggestion
algorithms prefix checks.
Before
```
error: unexpected argument '--ignored' found
tip: a similar argument exists: '--ignore-rust-version'
Usage: cargo test --ignore-rust-version [TESTNAME] [-- [ARGS]...]
For more information, try '--help'.
```
After
```
error: unexpected argument '--ignored' found
tip: a similar argument exists: '--ignore-rust-version'
tip: to pass '--ignored' as a value, use '-- --ignored'
Usage: cargo test --ignore-rust-version [TESTNAME] [-- [ARGS]...]
For more information, try '--help'.
```
Fixes#12494
fix: Don't duplicate comments when editing TOML
### What does this PR try to resolve?
`toml_edit` <0.22 has a bug that will cause
```toml
[lints]
rust.unsafe_op_in_unsafe_fn = "deny"
rust.explicit_outlives_requirements = "warn"
# rust.unused_crate_dependencies = "warn"
clippy.cast_lossless = "warn"
clippy.doc_markdown = "warn"
clippy.exhaustive_enums = "warn"
```
to be written out as
```toml
[lints]
rust.unsafe_op_in_unsafe_fn = "deny"
rust.explicit_outlives_requirements = "warn"
# rust.unused_crate_dependencies = "warn"
clippy.cast_lossless = "warn"
# rust.unused_crate_dependencies = "warn"
clippy.doc_markdown = "warn"
# rust.unused_crate_dependencies = "warn"
clippy.exhaustive_enums = "warn"
```
when it is parsed and then saved.
See toml-rs/toml#673
This affects any format-preserving edits we do, including:
- `cargo add`
- `cargo remove`
- `cargo init` / `cargo new` editing the workspace
### How should we test and review this PR?
I didn't add any tests as this is covered by `toml_edit`s tests (we already don't cover a fraction of the edit preserving tests it has)
### Additional information
`toml_edit` <0.22 has a bug that will cause
```toml
[lints]
rust.unsafe_op_in_unsafe_fn = "deny"
rust.explicit_outlives_requirements = "warn"
clippy.cast_lossless = "warn"
clippy.doc_markdown = "warn"
clippy.exhaustive_enums = "warn"
```
to be written out as
[lints]
rust.unsafe_op_in_unsafe_fn = "deny"
rust.explicit_outlives_requirements = "warn"
clippy.cast_lossless = "warn"
clippy.doc_markdown = "warn"
clippy.exhaustive_enums = "warn"
```
when it is parsed and then saved.
See toml-rs/toml#675
This affects any format-preserving edits we do, including:
- `cargo add`
- `cargo remove`
- `cargo init` / `cargo new` editing the workspace
