-
-
Notifications
You must be signed in to change notification settings - Fork 787
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
suggest unlocking locked pkgs that cause dep resolution failures #3970
base: main
Are you sure you want to change the base?
Conversation
fc51146
to
d40fb24
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Thank you!
I think the logic for deciding when to offer isn't quite right at the moment, I've left comment inline.
Could you also remove the new error variants that have been added please- we don't want to change anything about the errors shown in this case.
compiler-core/src/error.rs
Outdated
}) | ||
ResolutionError::Failure(err) => { | ||
let default_msg = format!("Dependency resolution was cancelled. {err}"); | ||
if err.contains(", but it is locked to") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this logic is correct. That error message is created when a locked version falls outside the requested version constraint, but that's not the situation in which we want to offer to unlock packages. We want to unlock if there's a conflict and any of the packages in the conflict are locked to specific versions.
I don't think such logic should be in the error module as it is only concerned with the definition, construction, and displaying of errors. It doesn't know anything about the wider context of the program or why errors would be emitted.
For sure, ty for review. And yeah I'll revisit the error logic and remove the |
Resolves #3622