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

Refactor context to extract dependencies calculation to a separate mod #5232

Merged
merged 1 commit into from
Mar 25, 2018

Conversation

matklad
Copy link
Member

@matklad matklad commented Mar 23, 2018

This makes unit dependency graph construction eager and moves it to a separate file.

Hopefully, this makes Context slightly easier to understand :)

@rust-highfive
Copy link

r? @alexcrichton

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

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

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

An awesome refactoring, thanks!

})
}

pub fn lib_or_check_profile<'a, 'cfg>(
Copy link
Member

Choose a reason for hiding this comment

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

I think this may not need to be public, right?

cx: &Context<'a, 'cfg>,
deps: &'b mut HashMap<Unit<'a>, Vec<Unit<'a>>>,
) -> CargoResult<&'b [Unit<'a>]> {
if !deps.contains_key(unit) {
Copy link
Member

Choose a reason for hiding this comment

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

I might find this a bit clearer as:

match deps.entry(*unit) {
    Entry::Occupied(v) => v.into_ref(), // or whatever the method is
    Entry::Vacant(v) => v.insert(calculate_deps(...)),
}

Copy link
Member

Choose a reason for hiding this comment

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

I may be missing something here, though? Is it required to insert into the map before we do the recursive step? I would have figured that the recursion would have been ruled out by this point...

Copy link
Member Author

Choose a reason for hiding this comment

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

.entry would not work here, because we need mutable access to deps in the call to calculate_deps :(

The recursion here is needed only for side effects: we want to fill dependencies not only for root units, but for the whole transitive closure. Ideally, this function should have returned (), but we actually call it recursively when we figure out deps for custom_build.

Copy link
Member

Choose a reason for hiding this comment

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

Hm ok I'm still not 100% following but that's fine, can clean it up as need be in the future

/// The `unit` provided must represent an execution of a build script, and
/// the returned set of units must all be run before `unit` is run.
pub fn dep_run_custom_build(&self, unit: &Unit<'a>) -> CargoResult<Vec<Unit<'a>>> {
// TODO: this ideally should be `-> &[Unit<'a>]`
Copy link
Member

Choose a reason for hiding this comment

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

Is this not possible due to various methods that take &mut self on Context?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep! Specifically, this happens because target_filenames and target_metadatas are calculated lazily. I hope to refactor them out as well, and change a whole bunch of methods from &mut to &.

});
// Note there's a subtlety about this piece of code! The
// `build_script_overridden` map here is populated in
// `custom_build::build_map` which you need to call before inspecting
Copy link
Member

Choose a reason for hiding this comment

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

This is here because build_map requires dep_targets, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes!

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Mar 25, 2018

📌 Commit 1b63fcf has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Mar 25, 2018

⌛ Testing commit 1b63fcf with merge 607f954...

bors added a commit that referenced this pull request Mar 25, 2018
Refactor context to extract dependencies calculation to a separate mod

This makes unit dependency graph construction eager and moves it to a separate file.

Hopefully, this makes `Context` slightly easier to understand :)
@bors
Copy link
Contributor

bors commented Mar 25, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 607f954 to master...

@bors bors merged commit 1b63fcf into rust-lang:master Mar 25, 2018
@bors bors mentioned this pull request Mar 25, 2018
@matklad matklad deleted the unit-map branch April 7, 2018 15:24
@ehuss ehuss added this to the 1.26.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants