fix(prerelease): preserve locked prerelease deps by weihanglo · Pull Request #17464 · rust-lang/cargo

weihanglo · 2026-09-11T05:07:37Z

What does this PR try to resolve?

This implements the consumption side of for prerelease version pinning, addressing the issue mentioned in #13290 (comment) (and all the above bug reports)

The initial implementation only dealt with the the resolution creation side (cargo update --precise <prerelease>), but we never touched how the pinned prerelease versions in lockfile are consumed for subsequent cargo commands.

In order to use the pinned prerelease for subsequent cargo commands beyond cargo update, this adds a new standalone flag -Zprerelease. Previously it was under the umbrella flag -Zunstable-options in cargo update.

How to test and review this PR?

The concept of the implementation is simple: Introduce a new enum modeling version request match mode.

Default for the default semver matching semantics
Prerelease for additional pre-release matching

However, the area this PR touching is messy, and the lockfile consumption site is hard to identify. This is my best-effort work, though I am not sure if it is done 100% correct.

Here is how I checked whether it needs the default semantic or extra prerelease semantic:

If an OptVersionReq is Locked or Precise, just use the Default mode. Mode makes no difference if it is already exact. For example, code block under req.is_locked() condition doesn't need prerelease mode.
Prerelease mode can only come from lockfile or --precise. Otherwise we may accidentally select more candidates.

Future extensions

While We mostly only want to apply prerelease mode on lockfile consumption side + pre-existing cargo update --precise locations at this moment, in the future we can probably make this configurable via resolver.prerelease accepting deny|locked-only|fallback|preferred or else.
There are some other "extensions" like supporting [patch]/[replace]. I meant like whether a [patch] entry of a prerelease version is applicable. I deferred them to future PRs as it is not purely lockfile consumption fix and the RFC didn't mention that, so not going do it right now.

🤖 LLM disclosure: LLM helped me find some more edge cases in [patch]. Code are hand written though.

rustbot · 2026-09-11T05:07:43Z

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @epage, @weihanglo
@epage, @weihanglo expanded to epage, weihanglo

weihanglo

Sorry this is not easy to review. Let me know if you want more smaller chunks.

View changes since this review

weihanglo · 2026-09-11T05:09:23Z

                // have a match whatsoever. Otherwise we need to check
                // `[patch]`...
-                if !dep.matches_ignoring_source(id, mode) {
+                if !dep.matches_ignoring_source(id, VersionReqMatchMode::Default) {


This needs to stick to the default mode because we don't currently support matching prerelease from a [patch] entry

weihanglo · 2026-09-11T05:12:58Z

        assert!(!self.patches_locked);

-        let mode = VersionReqMatchMode::Default;
+        let mode = if self.gctx.cli_unstable().prerelease {


This is asking whether a previously locked matches dependency requirement from a [patch] entry, not the version of [patch] itself.

weihanglo · 2026-09-11T05:16:12Z

cc @celinval

epage · 2026-09-11T17:42:24Z

Is this the right direction to go?

We could let people opt-in this feature. However, this feature is now behind -Zunstable-options for only cargo update. We could switch back to a dedicated -Zprerelease unstable flag, so people can opt-in this behavior for commands like cargo build and other build commands. What do people think?

I would have assumed the fix would be to do this.

weihanglo · 2026-09-11T20:13:52Z

Yeah, that is what this PR is doing. Both consumption and generation side require -Zprerelease flag.

Were you thinking of a different implementation or anything I am missing?

celinval

Awesome. Thanks for doing this, @weihanglo!

View changes since this review

celinval · 2026-09-15T20:39:09Z

@@ -1,4 +1,4 @@
-# Unstable Features
+# Unstable Featuresunstable.md


typo?

Suggested change

# Unstable Featuresunstable.md

# Unstable Features

My neovim love pasting nonsense.

celinval · 2026-09-15T20:41:20Z

 ```

-It's possible to update `my-dependency` to a pre-release with `update -Zunstable-options my-dependency --precise 0.1.2-pre.0`.
+It's possible to update `my-dependency` to a pre-release with `update -Zprerelease my-dependency --precise 0.1.2-pre.0`.


Can we document that the same feature has to be enabled for subsequent cargo commands?

Added in dcd3c7a.
Let me know if it is good.

Perfect! Thank you

`-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.

rustbot · 2026-09-18T02:36:05Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned epage Sep 11, 2026

weihanglo commented Sep 11, 2026

View reviewed changes

weihanglo changed the title ~~fix(prerelease): preserve locked prerelease deps from patches~~ fix(prerelease): preserve locked prerelease deps Sep 11, 2026

weihanglo force-pushed the precise-prerelease-pins branch from 97382f3 to dd76ab8 Compare September 14, 2026 18:48

This comment has been minimized.

Sign in to view

celinval reviewed Sep 15, 2026

View reviewed changes

weihanglo force-pushed the precise-prerelease-pins branch from dd76ab8 to dcd3c7a Compare September 15, 2026 23:51

This comment has been minimized.

Sign in to view

weihanglo added 8 commits September 17, 2026 22:35

fix: switch -Zprerelease for --precise <prerelease>

22b1d4c

`-Zunstable-options` only gates `cargo update` for generation side. This prepare use it in consumption side, for example, `cargo build -Zprerelease`.

refactor: parameterize version requirement matching

dfc9401

test: show buggy --precise <prerelease> locked versions

ab1163d

The second resolution either replaces the locked prerelease, or fails when another dep requires a non-prerelease requirement.

fix: preserve locked prerelease with -Zprerelease

1996357

Use prerelease if they are in `Cargo.lock` already, so locked prerelease survive subsequent resolution.

test: show [patch] drops locked prerelease

74db40d

fix: preserve locked prerelease deps from patches

1e91788

test: show --precise dropped with a locked prerelease

b7254ba

fix(update): prelease match mode with locked prerelease

fe2a5ac

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.

docs(prerelease): stick to -Zprelease for using locked versions

c84bd1c

weihanglo force-pushed the precise-prerelease-pins branch from dcd3c7a to c84bd1c Compare September 18, 2026 02:36

		@@ -1,4 +1,4 @@
		# Unstable Features
		# Unstable Featuresunstable.md

Uh oh!

Conversation

weihanglo commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Future extensions

Uh oh!

rustbot commented Sep 11, 2026

Uh oh!

weihanglo left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo commented Sep 11, 2026

Uh oh!

epage commented Sep 11, 2026

Uh oh!

weihanglo commented Sep 11, 2026

Uh oh!

This comment has been minimized.

celinval left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

celinval Sep 15, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Sep 15, 2026

Choose a reason for hiding this comment

Uh oh!

celinval Sep 15, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Sep 15, 2026

Choose a reason for hiding this comment

Uh oh!

celinval Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

weihanglo commented Sep 11, 2026 •

edited

Loading

weihanglo left a comment •

edited by rustbot

Loading

celinval left a comment •

edited by rustbot

Loading