cargo: fix pre-release version constraint handling

[joaquinhuigomez]

Fixes #15636

Meson's version_compare treats pre-release suffixes (e.g. 0.8.0-rc.7) as greater than the stable release, but semver specifies the opposite. This causes dependency resolution to fail when a stable version like 0.8.0 should satisfy >= 0.8.0-rc.7.

Strip pre-release suffixes when converting Cargo version constraints to meson format so that stable versions correctly satisfy pre-release constraints.

[jon-turney]

Meson's version_compare treats pre-release suffixes (e.g. 0.8.0-rc.7) as greater than the stable release, but semver specifies the opposite

This seems like kind of a hack: Maybe if these versions are to be compared using semver rules, we should have an actual implementation of that? Which would make it easier to surface support for that kind of comparison into meson.build, if that's ever needed.

It seems like I actually sketched out an implementation for making version_compare take a scheme parameter, long ago, in #4017 (linked to in #4017 (comment)), but there didn't seem much use for it back then...

[joaquinhuigomez]

Fair point — a proper semver scheme parameter would be cleaner than patching the default comparator. Happy to rework this toward that approach if you think it's worth reviving the idea from #4017.

[dcbaker]

Our default version compare is rpm compatible, and I'd prefer to keep it that way for consistency (though I probably wouldn't have picked the RPM format if I was implementing it). This matters because pkg-config uses an RPM compatible version comparison.

There's a lot of of hackery we do to make cargo/rust versions work correctly, and having a builtin handler of some kind makes sense to me. @bonzini on the cargo part

[joaquinhuigomez]

Makes sense to keep rpm as the default. Happy to wait for input from @bonzini on the cargo side before deciding the direction here.

[bonzini]

I like the idea of adding a scheme argument to version_compare , which can be rpm or semver. This would only have to affect the parsing because semver can be represented as major,minor,patch,-1,prerelease and reuse the comparison logic in Version.

Bonus points for a FeatureDeprecated if either version has an alphanumeric component and no scheme is provided.

[joaquinhuigomez]

That makes sense — parsing semver into the existing Version tuple format keeps the comparison logic clean. I'll rework the PR to add a scheme parameter. Will look at adding the FeatureDeprecated for unspecified alphanumeric components too.