test(metadata): Show behavior with TOML-specific types
### What does this PR try to resolve?
The goal is to know if/when these change so we can have a conversation about what to do.
### How should we test and review this PR?
### Additional information
Switch to using gitoxide by default for listing files
### What does this PR try to resolve?
Uses gitoxide by for listing the contents of a git repository by default. Fixes#10150
It's possible out-opt of this change with the environment variable `__CARGO_GITOXIDE_DISABLE_LIST_FILES=1`. This opt-out mechanism is temporary and will be removed before the next release.
### How should we test and review this PR?
The newly added test fails with the `git2` implementation.
Allow precise update to prerelease.
### What does this PR try to resolve?
This is a feature that attempts to support updates to pre-release versions via `cargo update --precise`.
when `precise-pre-release` used, the prerelase version will be taking consider as compatible version. That said, we can update to any compatible pre-release version. The logic of checking the compatibility of pre-release versions is currently tentative and does not take many conditions into account, this part of the logic makes more sense when implemented in semver.
Use `-Zunstable-options` instead of `-Zprecise-pre-release`.
### How should we test and review this PR?
### Additional information
Part of https://github.com/rust-lang/cargo/issues/13290
refactor(toml): Split out an explicit step to resolve `Cargo.toml`
### What does this PR try to resolve?
This builds on #13664 and #13666. Currently, once we have deserialized `Cargo.toml`, we pass it to a large machinery (`to_real_manifest`, `to_virtual_manifest`) so that
- `Cargo.toml` is resolved
- `Summary` is created
- `Manifest` is created
This splits out the resolving of `Cargo.toml` which is mostly workspace inheritance today.
While splitting logic conjoined like this can be a bit messy in the short term, the hope is that overall this makes the logic easier to follow (more condensed, focused sections to view; more explicit inputs/outputs).
In particular, I hope that this will make it clearer and easier to shift more logic into the resolving step, specifically the inferring of build targets for #13456.
### How should we test and review this PR?
This is broken up into very small steps in the hope that it makes it easier to analyze a step.
### Additional information
chore(deps): update rust crate base64 to 0.22.0
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [base64](https://togithub.com/marshallpierce/rust-base64) | workspace.dependencies | minor | `0.21.7` -> `0.22.0` |
---
### Release Notes
<details>
<summary>marshallpierce/rust-base64 (base64)</summary>
### [`v0.22.0`](https://togithub.com/marshallpierce/rust-base64/blob/HEAD/RELEASE-NOTES.md#0220)
[Compare Source](https://togithub.com/marshallpierce/rust-base64/compare/v0.21.7...v0.22.0)
- `DecodeSliceError::OutputSliceTooSmall` is now conservative rather than precise. That is, the error will only occur if the decoded output *cannot* fit, meaning that `Engine::decode_slice` can now be used with exactly-sized output slices. As part of this, `Engine::internal_decode` now returns `DecodeSliceError` instead of `DecodeError`, but that is not expected to affect any external callers.
- `DecodeError::InvalidLength` now refers specifically to the *number of valid symbols* being invalid (i.e. `len % 4 == 1`), rather than just the number of input bytes. This avoids confusing scenarios when based on interpretation you could make a case for either `InvalidLength` or `InvalidByte` being appropriate.
- Decoding is somewhat faster (5-10%)
</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=-->
Normally, I prefer directly constructing something but I feel this works
better in this case so I can limit a lot of work that is coupled to a
`package` being present.
Since we still directly construct, just with `None`, I think this still
works.
fix: bash completion fallback in `nounset` mode
With the shell in `nounset` mode, the intended fallback to filename completion provokes an error:
```
$ cargo foo <TAB>bash: !opt_var: unbound variable
```
With the shell in `nounset` mode, the intended fallback to filename
completion provokes an error:
```
$ cargo foo <TAB>bash: !opt_var: unbound variable
```
CI: Update macos images to macos-13
This changes the CI workflows to use `macos-13` instead of `macos-latest`. `latest` is currently `macos-12`, but GitHub is [migrating](https://github.blog/changelog/2024-04-01-macos-14-sonoma-is-generally-available-and-the-latest-macos-runner-image/) latest to `macos-14` starting immediately. 14 switches to aarch64 which we do not want, yet.
rust-lang/rust already migrated to macos-13 a little while ago in https://github.com/rust-lang/rust/pull/113544. This might have some performance improvements here, as the macos-12 images inconsistently have SIP enabled, but macos-13 seems to reliably have it disabled.
We do not yet know when GitHub will be retiring their x86_64 runners. Their current roadmap, posted at https://github.com/actions/runner-images/issues/9255, shows macos-13 supported through at least the end of the year. However, I suspect next year might spell the end for it. At that time, the Rust project might need to consider downgrading x86_64-apple-darwin to tier 2 or figure out some other option.
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=-->
