Document build-plan as being deprecated
This adds a note to the build-plan documentation that it is deprecated. I do not think it will make any progress as it is. In the future, we should remove the feature (#7902), possibly with a code-warning ahead of time.
fix(complete): Don't complete files for any value
### What does this PR try to resolve?
We now need to opt-in to path completions for values, which can be as simple as setting the value parser to be for `PathBuf`s.
We'll now show a lot less irrelevant completions.
### How should we test and review this PR?
### Additional information
Add more SAT resolver tests
### What does this PR try to resolve?
This is a follow-up of #14583.
### How should we test and review this PR?
* Commit 1 splits tests into smaller modules.
* Commit 2 adds more helper trait methods.
* Commit 3 refactors computation of the SAT clauses, by introducing intermediate boolean variables for each dependency and each dependency feature declared in a package.
The old behavior was incorrect: package features specified in an optional dependency were activated if the package was activated, even if the dependency wasn't activated.
* Commit 4 add tests from https://github.com/Eh2406/pubgrub-crates-benchmark/tree/main/out/index_ron.
r? Eh2406
fix: avoid inserting duplicate `dylib_path_envvar` when calling `cargo run` recursively
### What does this PR try to resolve?
If the current program started by `cargo run` recursively call into `cargo run`, the second `cargo run` will insert `search_path` into `dylib_path_envvar` again.
Fixes#14194
### How should we test and review this PR?
The first commit adds the test to reflect the issue. The first call to `cargo run` stores the dylib search path env var to a file. Subsequent calls verify that env var remains the same.
The second commit fixes the behavior by checking if env vars in `search_path` are a prefix of the slice of env vars in `dylib_path_envvar`.
Add new intermediate boolean variables for each dependency and each dependency feature declared in a package.
This is used to simplify computation of the sat clauses.
Add support for multiple dependencies with the same name, if their kind or target is different.
A non-weak dependency feature for an optional dependency now activates a feature of the same name in the sat resolver.
We now need to opt-in to path completions for values, which can be as
simple as setting the value parser to be for `PathBuf`s.
We'll now show a lot less irrelevant completions.
chore(deps): bump gix-path from 0.10.9 to 0.10.11
Bumps [gix-path](https://github.com/Byron/gitoxide) from 0.10.9 to 0.10.10.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/Byron/gitoxide/releases">gix-path's releases</a>.</em></p>
<blockquote>
<h2>gix-path v0.10.10</h2>
<p>A maintenance release without user-facing changes.</p>
<h3>Commit Statistics</h3>
<ul>
<li>6 commits contributed to the release over the course of 12 calendar days.</li>
<li>35 days passed between releases.</li>
<li>0 commits were understood as <a href="https://www.conventionalcommits.org">conventional</a>.</li>
<li>0 issues like '(#ID)' were seen in commit messages</li>
</ul>
<h3>Commit Details</h3>
<!-- raw HTML omitted -->
<!-- raw HTML omitted -->
<ul>
<li><strong>Uncategorized</strong>
<ul>
<li>Prepare changelogs prior to release (0f25841)</li>
<li>Merge pull request <a href="https://redirect.github.com/Byron/gitoxide/issues/1523">#1523</a> from martinvonz/push-xmsuurxprnnw (83c9de0)</li>
<li>Remove <code>--system</code> from <code>git config</code> call as it fails on MacOS (6b1c243)</li>
<li>Run <code>git config -l</code> in temp dir when looking up system config (20ef4e9)</li>
<li>Merge branch 'push-ysnqkzlzwuwq' (e2c747d)</li>
<li>Don't show console on Windows (087594c)</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="d19af16e1d"><code>d19af16</code></a> Release gix-date v0.9.0, gix-actor v0.31.6, gix-validate v0.9.0, gix-object v...</li>
<li><a href="0f2584178a"><code>0f25841</code></a> prepare changelogs prior to release</li>
<li><a href="9ed2b24e5d"><code>9ed2b24</code></a> Merge branch 'improvements'</li>
<li><a href="6990afd269"><code>6990afd</code></a> fix: similarity detection</li>
<li><a href="f8c5d9ce87"><code>f8c5d9c</code></a> fix similarity detection</li>
<li><a href="25a3f1b0b0"><code>25a3f1b</code></a> Merge pull request <a href="https://redirect.github.com/Byron/gitoxide/issues/1531">#1531</a> from EliahKagan/progress-typos</li>
<li><a href="ba72ee0f06"><code>ba72ee0</code></a> fix!: better peeling performance for reference traversal.</li>
<li><a href="9f9feb6545"><code>9f9feb6</code></a> add progress report for July</li>
<li><a href="b31d6b79fd"><code>b31d6b7</code></a> Fix typos in config support info</li>
<li><a href="242fedc973"><code>242fedc</code></a> Merge branch 'improvements'</li>
<li>Additional commits viewable in <a href="https://github.com/Byron/gitoxide/compare/gix-path-v0.10.9...gix-path-v0.10.10">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR by commenting ``@dependabot` rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/rust-lang/cargo/network/alerts).
</details>
> **Note**
> Automatic rebases have been disabled on this pull request as it has been open for over 30 days.
improve error reporting when feature not found in `activated_features`
Pulls the error message refactor out of #14593 (originally #13207) to improve error reporting when we fail to get the list of activated features enabled for the given package. It now fully lists the activated_features hashmap keys too.
From the [original author](https://github.com/rust-lang/cargo/pull/13207#issue-2056019109):
> I moved `activated_features_int` into `activated_features` and `activated_features_unverified` as I was concerned of the performance cost of generating the full error when its not a fatal error and may occur many times.
Old vs new error message:
```diff
- activated_features for invalid package: features did not find PackageId { name: "bindep", version: "0.0.0", source: "[ROOT]/foo/bindep" } NormalOrDev
+ did not find features for (PackageId { name: "bindep", version: "0.0.0", source: "[ROOT]/foo/bindep" }, NormalOrDev) within activated_features:
+ [
+ (
+ PackageId {
+ name: "bindep",
+ version: "0.0.0",
+ source: "[ROOT]/foo/bindep",
+ },
+ ArtifactDep(
+ CompileTarget {
+ name: "[ALT_TARGET]",
+ },
+ ),
+ ),
+ (
+ PackageId {
+ name: "foo",
+ version: "0.0.0",
+ source: "[ROOT]/foo",
+ },
+ NormalOrDev,
+ ),
+ ]
```
r? weihanglo
test: Remove the last of our custom json assertions
### What does this PR try to resolve?
This is part of #14039 and consolidates us down to only one way of doing json assertions, using snapbox.
### How should we test and review this PR?
### Additional information
This includes
- `cargo generate-lockfile --ignore-rust-version`
- `cargo update --ignore-rust-version`
This does not include
- `edition = "2024"`
- `resolver = "3"`
docs(ref): Expand on MSRV
### What does this PR try to resolve?
The need for this has been growing and becomes especially important with the upcoming MSRV aware resolver
We will be making having an MSRV easier so we need to meet those maintainers where they are and help them.
In particular, this covers
- What setting an MSRV does
- What "support" in MSRV means, according to the definition we developed during the review of [RFC 3537](https://rust-lang.github.io/rfcs/3537-msrv-resolver.html)
- Background and guidance on setting an MSRV policy
### How should we test and review this PR?
### Additional information
This intentionally leaves out anything related to the MSRV-aware resolver as that will be handled as the feature is stabilized.
docs: Minor re-grouping of pages
### What does this PR try to resolve?
In figuring out where MSRV documentation should live, I found the location of some items confusing
- Publishing is written in more of a guide-form, rather than reference
- Caching is written in more of a reference form, rather than a guide, and is more advanced
- Dependency references were scattered, making it harder to find
### How should we test and review this PR?
### Additional information
docs(ref): Highleft whats left for msrv-policy
### What does this PR try to resolve?
While there is a tracking issue for these,
I didn't want to have everything under `msrv-policy` to be stabilized,
making it look like it should be moved to the Stable section of the
page, when there are independently stabilizable pieces missing.
### How should we test and review this PR?
### Additional information
This is prep for stabilizing MSRV-aware resover
While there is a tracking issue for these,
I didn't want to have everything under `msrv-policy` to be stabilized,
making it look like it should be moved to the Stable section of the
page, when there are independently stabilizable pieces missing.
It doesn't "guide" people through a topic but explains in a more
top-down fashion what caches exist and is not particularly a common
topic people need to know.
Fix `cargo:version_number` - has only one `:`
See [openssl code](8d60e21146/openssl-sys/build/main.rs (L392)) -- it uses a single colon. Also inlined arg into format to make it a bit more consice.
```rust
let openssl_version = openssl_version.unwrap();
println!("cargo:version_number={:x}", openssl_version);
if openssl_version >= 0x4_00_00_00_0 {
...
```
docs: Declare support level for each crate in our Charter / docs
### What does this PR try to resolve?
This is to bring us into conformance with the [Rust crate ownership policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo` does not have a status specified on it. `cargo install cargo` shouldn't be done and `cargo add cargo` is "internal" but putting in our README that Cargo is "internal" feels weird from a messaging perspective.
- `cargo-credential-1password` is declared as Experimental as it is intended for the community but I was unsure if we wanted to commit to full support for it. In my mind, the ideal thing to do would be to expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended for the wider ecosystem and I didn't see a reason to declare it experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared as Intentional as they are both used internally and intended for others to use for logic that integrates with cargo/registries. I wondered about these being Experimental or Internal instead.
### How should we test and review this PR?
I was mixed on what to do with unpublished crates (and didn't fully check what all is unpublished).
I ended up only skipping xtasks.
### Additional information
chore(deps): update tar to 0.4.42
The new version of tar enables the creation of sparse tar archives by default. The ability to read such sparse entries was added in tar 0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12. Additionally, `docker cp` doesn't support sparse tar entries in the GNU format. For compatibility with older versions of Rust and Cargo, as well as with `docker cp`, this commit disables sparse archive creation everywhere the `tar::Builder` is used.
Closes#14594. CC: `@weihanglo,` `@alexcrichton.`
The new version of tar enables the creation of sparse tar archives by
default. The ability to read such sparse entries was added in tar
0.4.6, which has been in use starting from Cargo 0.13 and Rust 1.12.
Additionally, `docker cp` doesn't support sparse tar entries in the GNU
format. For compatibility with older versions of Rust and Cargo, as
well as with `docker cp`, this commit disables sparse archive creation
in the corresponding cases where the `tar::Builder` is used. See
#14594.
docs(charter): Declare new Intentional Artifacts as 'small' changes
### What does this PR try to resolve?
The default stance for new "Intentional Artifact" crates is that an RFC is needed, see [Crate ownership policy](https://forge.rust-lang.org/policies/crate-ownership.html).
However, it gives room for team's to have their charter define the process. As we don't generally need wide input for these decisions, I'm proposing we treat these as "small" changes and only require an FCP.
### How should we test and review this PR?
### Additional information
fix: Remove implicit feature removal
### What does this PR try to resolve?
Due to problems we ran into with #14016, we're removing implicit features from the 2024 edition to give ourselves more time to design it as we should.
### How should we test and review this PR?
### Additional information
I could have added a new flag for this or made an EditionNext but I decided to remove it in the hopes to avoid any path dependency in solving this the next time.
chore(deps): update rust crate unicode-width to 0.2.0
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [unicode-width](https://redirect.github.com/unicode-rs/unicode-width) | workspace.dependencies | minor | `0.1.13` -> `0.2.0` |
---
### Release Notes
<details>
<summary>unicode-rs/unicode-width (unicode-width)</summary>
### [`v0.1.14`](https://redirect.github.com/unicode-rs/unicode-width/compare/v0.1.13...v0.1.14)
[Compare Source](https://redirect.github.com/unicode-rs/unicode-width/compare/v0.1.13...v0.1.14)
</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 was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzguOTcuMCIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
