Tracking Issue for update --precise with pre-release

[ehuss]

Summary

RFC: #3493
Original issue: #12579
Implementation: #13626
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#precise-pre-release

Extends cargo update --precise to allow pre-release versions, even if the dependency declarations do not specify a pre-release.

Unresolved Issues

• Upstream pre-release match logic to semver crate
• Upper bound semantic. See the unresolved questions in the RFC.

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[linyihai]

Since #13296 had merged, i think i can lend a hand to continue.

Just in case I forgot, I was gonna @rustbot claim.

[epage]

I believe @eopb was planning on working on this. I'd recommend coordinating with them

[eopb]

Thanks Ed. Yes, I'm still intending to work on this. If you'd like to help @linyihai, please reach out to me on zulip (under the same username as here).

I'm sure we can work together. The last thing I'd want to do is to slow things down by trying to hog this tracking issue.

[linyihai]

Yes, I'm still intending to work on this. I'm sure we can work together. The last thing I'd want to do is to slow things down by trying to hog this tracking issue.

I'm sorry that I started the claim without further understanding of the requirement. You're the one who came up with this RFC, so I'm sure you know more details than I do. If you think it's better to do it yourself, that's fine. If you need help, break it down into smaller issues so that others see it and can help @eopb

please reach out to me on zulip (under the same username as here).

I'll be in touch if I need anything. Thank you @eopb

[linyihai]

FYI，I recently tried to implement an MVP based on RFC content.

[weihanglo]

#14013 shows the current implementation is a bit buggy, and there are upper bound semantic issues not yet resolved. See these test cases:

cargo/src/cargo/util/semver_ext.rs

Lines 204 to 233 in 050f88c

	let cases = [
	//
	("1.2.3", "1.2.3-0", true), // bug, must be false
	("1.2.3", "1.2.3-1", true), // bug, must be false
	("1.2.3", "1.2.4-0", true),
	//
	(">=1.2.3", "1.2.3-0", true), // bug, must be false
	(">=1.2.3", "1.2.3-1", true), // bug, must be false
	(">=1.2.3", "1.2.4-0", true),
	//
	(">1.2.3", "1.2.3-0", false),
	(">1.2.3", "1.2.3-1", false),
	(">1.2.3", "1.2.4-0", true),
	//
	(">1.2.3, <1.2.4", "1.2.3-0", false),
	(">1.2.3, <1.2.4", "1.2.3-1", false),
	(">1.2.3, <1.2.4", "1.2.4-0", false), // upper bound semantic
	//
	(">=1.2.3, <1.2.4", "1.2.3-0", true), // bug, must be false
	(">=1.2.3, <1.2.4", "1.2.3-1", true), // bug, must be false
	(">=1.2.3, <1.2.4", "1.2.4-0", false), // upper bound semantic
	//
	(">1.2.3, <=1.2.4", "1.2.3-0", false),
	(">1.2.3, <=1.2.4", "1.2.3-1", false),
	(">1.2.3, <=1.2.4", "1.2.4-0", true),
	//
	(">=1.2.3-0, <1.2.3", "1.2.3-0", false), // upper bound semantic
	(">=1.2.3-0, <1.2.3", "1.2.3-1", false), // upper bound semantic
	(">=1.2.3-0, <1.2.3", "1.2.4-0", false),
	];

It is technically possible to fix them inside cargo. However to do that we'll need to duplicate the logic in semver crate. I am in the team of upstreaming things to semver.

[linyihai]

Yes, The semver crate only supports to compare prerelease with prerelease if I remember correct，
https://docs.rs/semver/latest/src/semver/eval.rs.html#14-21

 // If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it
    // will only be allowed to satisfy req if at least one comparator with the
    // same major.minor.patch also has a prerelease tag.
    for cmp in &req.comparators {
        if pre_is_compatible(cmp, ver) {
            return true;
        }
    }

So we need to add the pre tag to the version_req in order to use the semver crate, like RFC writes:

So before,

1.2.3  -> ^1.2.3 -> >=1.2.3, <2.0.0 (with implicit holes excluding pre-release versions)
would become

1.2.3  -> ^1.2.3 -> >=1.2.3, <2.0.0-0

[linyihai]

I have drafted a semver side PR to address upper bound semantic, but it stucks on node tests.

Also, my changes to cargo can be viewed in detail in this branch, which seems to solve the problem

[linyihai]

After some experiments on semver PR, I found something interesting,

• the semver crate matches implementaion may be based on node semver compatibility. the semver matches follow the limit if the version has a prerelease tag then its MAJOR.MINOR.PATCH must be same with the VersionReq at least once, and another issuse is it can't handle partial VersionReq
• By removing the limit and handle the partial VersionReq, the first proposed semantic came out. The prerelease tag padding logic has some controversial, like '<4.2', we chose pading it to '<4.2.0' not '<4.2.0-0' .

By look into the node semver compatibility semantic, it offers includePrerelease=true to remove the limit, then I add the test and try to implement it in semver, see dtolnay/semver#321 (comment). The result is the node semver compatibility implement ation also covers the semantic proposed by rust-lang/rfcs#3493.