fix: Limiting pre-release match semantics to use only on OptVersionReq::Req

[linyihai]

What does this PR try to resolve?

The prerelease matches semantics should be only used on OptVersionReq::Req, but it dosn't. The other OptVersionReq types have specify matches logic already, for example a OptVersionReq::Precise will failed on matches_prerelease, see #14140 (comment)

How should we test and review this PR?

the first commit added the test, the second commit updated the test and fixed the issue.

Additional information

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
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

[epage]

matches_prerelease should be only used on OptVersionReq::Req, but it dosn't.

Can you explain why?

[linyihai]

Thanks your swift review and forgive my typos.

matches_prerelease should be only used on OptVersionReq::Req, but it dosn't.

The currrent approach of matches_prerelease ignores the Prerelease tag, which will allows updating to any semver-compatible pre-rerelease version. (This approach is temporray).

But the OptVersionReq::Locked and OptVersionReq::Precise involve the Prerelease tag to match, they will fail in match if the VersiongReq is pre-release.

The current use of this function is OptVersionReq::Req,

cargo/src/cargo/sources/registry/mod.rs

Lines 750 to 765 in d585829

	let mut req = dep.version_req().clone();
	// Handle `cargo update --precise` here.
	if let Some((_, requested)) = self
	.source_id
	.precise_registry_version(dep.package_name().as_str())
	.filter(|(c, to)| {
	if to.is_prerelease() && self.gctx.cli_unstable().unstable_options {
	req.matches_prerelease(c)
	} else {
	req.matches(c)
	}
	})
	{
	req.precise_to(&requested);
	}

cargo/src/cargo/sources/registry/mod.rs

Lines 795 to 809 in d585829

	let mut precise_yanked_in_use = false;
	ready!(self
	.index
	.query_inner(dep.package_name(), &req, &mut *self.ops, &mut |s| {
	let matched = match kind {
	QueryKind::Exact => {
	if req.is_precise() && self.gctx.cli_unstable().unstable_options {
	dep.matches_prerelease(s.as_summary())
	} else {
	dep.matches(s.as_summary())
	}
	}
	QueryKind::Alternatives => true,
	QueryKind::Normalized => true,
	};

so it's safe to limit its usage

[epage]

But the OptVersionReq::Locked and OptVersionReq::Precise involve the Prerelease tag to match, they will fail in match if the VersiongReq is pre-release.

I think #14305 makes this a bit more clear. We are trying to emulate a proposed matches_prelease, so we should be modifying the behavior of matches. With where this was placed, we accidentally expanded the scope out further and applied it to Precise and Locked which the current hack is incompatible with and the semantics of those operations are for version equality and not version requirement matching.

[epage]

@bors r+

[bors]

📌 Commit 3a1bb8b has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 3a1bb8b with merge 1f4ef10...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 1f4ef10 to master...