Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(resolver): **Very** preliminary MSRV resolver support #12560

Merged
merged 3 commits into from
Aug 28, 2023

Conversation

epage
Copy link
Contributor

@epage epage commented Aug 25, 2023

What does this PR try to resolve?

A bare bones implementation of an MSRV resolver that is good enough for people running on nightly when they really need it but is not ready for general use.

Current limitations

  • Does not honor --ignore-version
  • Gives terrible error messages
  • Nothing is done yet regarding cargo install
  • Doesn't inform the user when choosing non-latest

These will be noted in #9930 on merge.

Implementation wise, this is yet another hack (sorry @Eh2406). Our expectation to get this GA is to refactor the resolver to make the cargo/resolver boundary look a little more like the cargo/pubgrub boundary so we can better control policy without any of these hacks which will also make having all of the policy we need for this easier to maintain.

This is a part of #9930

How should we test and review this PR?

Per commit

This was kept separate to show that the prior commit didn't change
anything for stable users.
@rustbot
Copy link
Collaborator

rustbot commented Aug 25, 2023

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added A-dependency-resolution Area: dependency resolution and the resolver A-semver Area: semver specifications, version matching, etc. A-workspaces Area: workspaces Command-fix Command-generate-lockfile Command-metadata Command-package Command-tree S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 25, 2023
@Eh2406
Copy link
Contributor

Eh2406 commented Aug 25, 2023

🙈

@@ -153,6 +154,7 @@ pub fn resolve_std<'cfg>(
&specs,
HasDevUnits::No,
crate::core::resolver::features::ForceAllTargets::No,
max_rust_version,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one case I'm not entirely sure of but since its another unstable feature, I figure doing a best effort isn't the end of the world

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not follow the point you were trying to make here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming this is build-std and we do a separate resolve pass for that. What should we consider max_rust_version to be in this case?

Comment on lines +153 to +158
if !config
.map(|c| c.cli_unstable().msrv_policy)
.unwrap_or(false)
{
max_rust_version = None;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I centralized the feature check to this one spot

I am somewhat tempted to do something similar for honor_rust_version and have the config initialized with it and just check the config here.

.success()
.code(101)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be undone when we get --ignore-rust-version working

Comment on lines +235 to +245
// This should have a better error message
.with_stderr(
"\
[UPDATING] `dummy-registry` index
[ERROR] failed to select a version for the requirement `bar = \"^1.0.0\"`
candidate versions found which didn't match: 1.6.0
location searched: `dummy-registry` index (which is replacing registry `crates-io`)
required by package `foo v0.0.1 ([CWD])`
perhaps a crate was updated and forgotten to be re-vendored?
",
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Example of the bad error message

Comment on lines +276 to +285
p.cargo("check --ignore-rust-version")
.arg("-Zmsrv-policy")
.masquerade_as_nightly_cargo(&["msrv-policy"])
// This should pick 1.6.0
.with_stderr(
"\
[UPDATING] `dummy-registry` index
[DOWNLOADING] crates ...
[DOWNLOADED] bar v1.5.0 (registry `dummy-registry`)
[CHECKING] bar v1.5.0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another example of --ignore-rust-version not working yet

@epage epage marked this pull request as ready for review August 26, 2023 02:01
@epage
Copy link
Contributor Author

epage commented Aug 26, 2023

🙈

r? @Eh2406

;)

@rustbot rustbot assigned Eh2406 and unassigned ehuss Aug 26, 2023
@Eh2406
Copy link
Contributor

Eh2406 commented Aug 28, 2023

There was discussion about modeling this as a dependency so that the resolver did not explicitly need to know about this new kind of requirement. What happened with that idea?

With this being part of the resolver is it possible to or is there value in adding this to proptest test generation?

@epage
Copy link
Contributor Author

epage commented Aug 28, 2023

There was discussion about modeling this as a dependency so that the resolver did not explicitly need to know about this new kind of requirement. What happened with that idea?

This is exclusively meant as an unstable hack to

  • Unblock people from getting this feature even if its not to the quality of stable
  • Allow us to iterate on other parts of the design while working on the resolver refactor

The resolver factor to get us to the state of this being a dependency is doing to be a bit of work and I figured this can allow us to decouple parts of the process for this feature.

With this being part of the resolver is it possible to or is there value in adding this to proptest test generation?

As this implementation is only ever intended for unstable use, I would hold off but we can call this out in the issue as remaining work in case anything changes about the plan to ensure we have it before stabilization.

@Eh2406
Copy link
Contributor

Eh2406 commented Aug 28, 2023

As a reviewer I don't quite know what to say then. I can confirm that it is an unholy hack. But, doing things properly is not in scope for this PR. The way it's implemented it should not corrupt internal data structures or cause other similar problems. What other feedback would you find useful from your reviewer?

Is there other work you would like to do before this hack gets Merged?

@epage
Copy link
Contributor Author

epage commented Aug 28, 2023

I am fine with it being merged as-is but with this touching the resolver, I wanted you to both review the work and get your Ok on doing this unholy hack.

@Eh2406
Copy link
Contributor

Eh2406 commented Aug 28, 2023

@bors r=🙈eh2406🙈

@bors
Copy link
Collaborator

bors commented Aug 28, 2023

📌 Commit 4abd05e has been approved by 🙈eh2406🙈

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 28, 2023
@bors
Copy link
Collaborator

bors commented Aug 28, 2023

⌛ Testing commit 4abd05e with merge 0c2b370...

@bors
Copy link
Collaborator

bors commented Aug 28, 2023

☀️ Test successful - checks-actions
Approved by: 🙈eh2406🙈
Pushing 0c2b370 to master...

@bors bors merged commit 0c2b370 into rust-lang:master Aug 28, 2023
19 checks passed
@epage epage deleted the msrv branch August 28, 2023 22:54
@Eh2406
Copy link
Contributor

Eh2406 commented Aug 29, 2023

Having slept on this I think I was too harsh. I have done worse things this code base, some of which I have not succeeded at removing. It is a hack, but "unholy" was unfair of me.

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 29, 2023
Update cargo

18 commits in 925280f028db3a322935e040719a0754703947cf..96fe1c9e1aecd8f57063e3753969bb6418fd2fd5
2023-08-25 21:16:44 +0000 to 2023-08-29 20:10:34 +0000
- fix(lints): Fail when overriding inherited lints (rust-lang/cargo#12584)
- cargo install: suggest --git when package name is url (rust-lang/cargo#12575)
- chore: remove unstable-options for logout (rust-lang/cargo#12588)
- Improve logout message for asymmetric tokens (rust-lang/cargo#12587)
- fix(update): Remove references to -p in help (rust-lang/cargo#12586)
- fix(update): Make `-p` more convenient by being positional (rust-lang/cargo#12545)
- Set tracing target for networking messages. (rust-lang/cargo#12582)
- Retry docs (rust-lang/cargo#12583)
- feat(resolver): **Very** preliminary MSRV resolver support (rust-lang/cargo#12560)
- Update git2 (rust-lang/cargo#12580)
- Explain how `version` works for `git` dependencies (rust-lang/cargo#12270)
- Improve deserialization errors of untagged enums (rust-lang/cargo#12574)
- Add support for `target.'cfg(..)'.linker` (rust-lang/cargo#12535)
- Improve resolver version mismatch warning (rust-lang/cargo#12573)
- Stabilize `--keep-going` (rust-lang/cargo#12568)
- Define {{command}} for use in src/doc/man/includes (rust-lang/cargo#12570)
- Update serde (rust-lang/cargo#12569)
- chore: add missing `windows-sys` features back (rust-lang/cargo#12563)

r? ghost
@ehuss ehuss added this to the 1.74.0 milestone Sep 30, 2023
weihanglo added a commit to weihanglo/cargo that referenced this pull request Oct 20, 2023
MSRV-aware resolver has been implemented in rust-lang#12560.
Based on that effort, generating lockfile can now respect `rust-version`
so that a package with an old MSRV never generate a incompatiable
lockfile, even using the latest Cargo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver A-semver Area: semver specifications, version matching, etc. A-testing-cargo-itself Area: cargo's tests A-workspaces Area: workspaces Command-fix Command-generate-lockfile Command-metadata Command-package Command-tree S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants