Conversation
Keep explicit --locked coverage independent from tests for cargo install's default lockfile behavior.
Make registry and path installs honor Cargo.lock without requiring --locked. Keep fallback behavior when no lockfile is available, including the compatibility warning for explicit --locked.
Cargo install now honors an an available lockfile, so no caller needs Workspace::ignore_lock. Remove the unused state and unreachable resolver and MSRV-help branches while retaining the no-lockfile yanked-check guard.
weihanglo
changed the title
weihanglo
force-pushed
the
precise-prerelease-pins
branch
7 times, most recently
from
September 11, 2026 04:38
5c61bbf to
97382f3
Compare
…t-lang#17466) ### What does this PR try to resolve? Followup to the discussion from rust-lang#14774 (comment). I added test cases to pin how workspace feature unification interacts with: - `default-members` workspace Cargo.toml - `--exclude <package>` flag - v1 resolver - v2 resolver - `--all-features` flag - `--no-default-features` flag As for the ambiguous interactions mentioned in the comment, I think the following rule of thumb makes sense: since the goal of workspace feature unification is to avoid rebuilding artifacts, any interactions with flags/configs should not cause unnecessary rebuilds regardless of what packages are currently selected. That means for flags like `--all-features` and `--no-default-features`, the flag would apply to all members of the workspace despite what the documentation saying that it only applies to the selected packages. So I wrote all the tests with this in mind. Luckily this is already the current behavior of workspace feature unification and didn't require and changes to cargo. ### How to test and review this PR? New tests should make sense based on how we expect workspace feature unification to behave.
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/cargo/pull/17388)* ### What does this PR try to resolve? This PR closes rust-lang#7169 `cargo build` uses an existing `Cargo.lock`, while `cargo install` previously ignored a package's `Cargo.lock ` file unless `--locked` was passed. As a result, building and testing a binary could use one set of dependency version while installing the same binary selected another. This can cause installation to fail even though the package built and tested successfully. This also leaves maintainers supporting dependency versions they didn't test or sign-up for. Following [Cargo Team Decision](rust-lang#7169 (comment)), this PR makes `cargo install` use the available lockfile by default. This gives `cargo install` the existing behavior of `cargo install --locked`. `--locked` remains accepted but it is a no-op. When a package does not contain a lockfile, Cargo fallback to resolving its deps normally. Explicitly passing `--locked` still emits the existing missing-lockfile warning. The warning for yanked deps is preserved, but it's suggestion to retry without `--locked` is removed because doing so no longer changes dep resolution. Deprecating `--locked` and adding an option to ignore the packaged lockfile remains a separate effort to be considered as discussed in the decision. ### How to test and review this PR? There are four commits structured in this manner: 1. Make the help attached to yanked-dependency warning optional without changing the existing behavior 2. Add tests to verify that `cargo install --locked` honors packaged lockfile. 3. Change installation behavior, update the affected tests, and update the generated documentation. 4. Remove now obsolete `ignore_lock` workspace state and resolver path. #### Test covers 1. Registry installation without the packaged lockfile by default. 2. Path installation using it's lockfile by default. 5. `--locked` remaining accepted and producing the same resolution. 6. Falling back to normal resolution when no published lockfile exists. 7. Git installation without a lockfile 8. Yanked dependencies continuing to warn without suggesting installation without `--locked`. 9. The existing `cargo-package` yanked-dependency help remaining unchanged. #### The following tests were run: ```text cargo test --test testsuite -- install::install_respects_lock_file cargo test --test testsuite -- install::install_path_respects_lock_file cargo test --test testsuite -- install::locked_install_ cargo test --test testsuite -- install::install_without_published_lockfile cargo test --test testsuite -- install::git_repo cargo test --test testsuite -- publish_lockfile::warn ```
As part of notifying users calling bare `rustc` without an explicit edition that they should likely be using the 2024 edition, update cargo tests to not trigger the new user facing note.
As part of notifying users calling bare `rustc` without an explicit edition that they should likely be using the 2024 edition, update cargo tests to not trigger the new user facing note. This change will let rust-lang/rust#158102 to land.
I like to be added to the review rotation.
…ng#17447) ### What does this PR try to resolve? This implements part of [RFC `feature-documentation`](rust-lang/rfcs#3485), tracked by rust-lang#17445. This only adds support for the new key in the schema. This doesn't add anything to the index as this was decided against. This doesn't not introduce a dedicated unstable feature, as mentioned in rust-lang#17445 (comment), and the new key is simply gated behind the existing `feature-metadata` unstable feature. The exact name of the key is still TBD, but it will be easy to rename either in this PR or later. ## Open questions - How to prepare the documentation for this? Not introducing an unstable feature means there is no dedicated place for that in the book, should it be added to [the existing docs of `feature-metadata` there](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#feature-metadata), or stacked as a separate PR on top of rust-lang#17446? ## Future work At least the following is still to be done for this RFC (I may not have time to tackle this): - Exposing the new key through `cargo metadata`. - Exposing the documentation to humans through `cargo add` (and through other tools/services, like [docs.rs](https://docs.rs)). ### How to test and review this PR? The tests should be enough to review this.
`-Zunstable-options` only gates `cargo update` for generation side. This prepare use it in consumption side, for example, `cargo build -Zprerelease`.
The second resolution either replaces the locked prerelease, or fails when another dep requires a non-prerelease requirement.
Use prerelease if they are in `Cargo.lock` already, so locked prerelease survive subsequent resolution.
We use prelease match mode for `--precies` when either "update to" or locked version is pre-release. Otherwise the entire `--precise` will be ignored because default mode doesn't match the locked prerelease version.
weihanglo
force-pushed
the
precise-prerelease-pins
branch
from
September 14, 2026 18:48
97382f3 to
dd76ab8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.