-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[DO NOT LAND] unify packages in ptb logic #20827
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
c7e35f9
to
9bbf9a6
Compare
} | ||
|
||
impl ConflictResolution { | ||
pub fn unify(&mut self, other: &ConflictResolution) -> anyhow::Result<()> { |
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.
Nit, I'd prefer
pub fn unify(&mut self, other: &ConflictResolution) -> anyhow::Result<()> { | |
pub fn unify(&self, other: &ConflictResolution) -> anyhow::Result<ConflictResolution> { |
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 always find these sort of mutable unifications harder to follow (but maybe thats just me)
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.
FWIW I significantly prefer them due to their efficiency improvements. In this instance, switching to return the value would require us to update the BTreeMap every time we do unification (or at least call std::mem::replace
at each call), whereas this does it directly.
} | ||
// If we have two exact resolutions, they must be the same. | ||
(ConflictResolution::Exact(sv, self_id), ConflictResolution::Exact(ov, other_id)) => { | ||
if self_id != other_id { |
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'm confused. Why aren't we checking the sv
and ov
?
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.
Is it because if the ids are the same, the sequence number should also be the same?
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.
Correct. But it doesn't hurt to double-check.
ConflictResolution::Exact(exact_version, self_id), | ||
ConflictResolution::AtLeast(at_least_version, oid), | ||
) | ||
| ( | ||
ConflictResolution::AtLeast(at_least_version, oid), | ||
ConflictResolution::Exact(exact_version, self_id), |
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.
nit
ConflictResolution::Exact(exact_version, self_id), | |
ConflictResolution::AtLeast(at_least_version, oid), | |
) | |
| ( | |
ConflictResolution::AtLeast(at_least_version, oid), | |
ConflictResolution::Exact(exact_version, self_id), | |
ConflictResolution::Exact(exact_version, exact_id), | |
ConflictResolution::AtLeast(at_least_version, at_least_id), | |
) | |
| ( | |
ConflictResolution::AtLeast(at_least_version, exact_id), | |
ConflictResolution::Exact(exact_version, at_least_id), |
if unification_table.contains_key(&package.original_package_id()) { | ||
let existing_unifier = unification_table | ||
.get_mut(&package.original_package_id()) | ||
.expect("Guaranteed to exist"); | ||
existing_unifier.unify(&resolution)?; | ||
} else { | ||
unification_table.insert(package.original_package_id(), resolution); | ||
} |
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.
unification_table
.entry(&package.original_package_id())
.and_modify(|existing_unifier| { existing_unifier.unify(&resolution)?; })
.or_insert(resolution);
for object_id in self.non_entry_functions.iter() { | ||
Self::add_and_unify( | ||
&mut unification_table, | ||
&self.all_packages, | ||
object_id, | ||
|pkg| { | ||
if linking_config.fix_top_level_functions { | ||
ConflictResolution::Exact(pkg.version(), pkg.id()) | ||
} else { | ||
ConflictResolution::AtLeast(pkg.version(), *object_id) | ||
} | ||
}, | ||
)?; | ||
} |
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.
A small nit for logic like this: consider moving it onto the linking_config
, as:
for object_id in self.non_entry_functions.iter() {
Self::add_and_unify(
&mut unification_table,
&self.all_packages,
object_id,
|pkg| linking_config.generate_top_level_function_constraint(pkg.version(), pkg.id(), object_id)
)?;
}
That way as the flags grow, we do not need to update their usage across the file; we can just ask the config what it should be.
45b83d3
to
5156d26
Compare
5156d26
to
86aabc3
Compare
86aabc3
to
57c7ce6
Compare
Description
Describe the changes or additions included in this PR.
Test plan
How did you test the new or updated feature?
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.