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

[incremental] Add support for eval always queries #45353

Merged
merged 4 commits into from Oct 27, 2017

Conversation

Projects
None yet
6 participants
@wesleywiser
Copy link
Member

wesleywiser commented Oct 18, 2017

Part of #45238

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Oct 18, 2017

r? @eddyb

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

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 18, 2017

@michaelwoerister
Copy link
Contributor

michaelwoerister left a comment

Looking good, except for the result fingerprinting being missing. Since we essentially disable dependency tracking for this tasks its even more important for them to be fingerprinted.

If you add the fingerprint, however, I guess there'll be a lot of code duplication between with_untracked_task and with_task. Maybe one can be implemented in the terms of the other.

I'm also a bit skeptical about the term untracked since it rather suggests the functionality that we already have with ignore.

@@ -782,6 +812,24 @@ impl CurrentDepGraph {
}
}

pub(super) fn push_untracked_task(&mut self, key: DepNode) {

This comment has been minimized.

@michaelwoerister

michaelwoerister Oct 18, 2017

Contributor

You should be able to make the push and the pop methods here private.

@@ -812,7 +860,7 @@ impl CurrentDepGraph {
reads.push(source);
}
}
Some(&mut OpenTask::Ignore) | None => {
Some(&mut OpenTask::Ignore) | Some(&mut OpenTask::Untracked { .. }) | None => {

This comment has been minimized.

@michaelwoerister

michaelwoerister Oct 18, 2017

Contributor

Since this line is getting a little long, it would be more readable to have each arm on its own line.

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 18, 2017

Hm, it looks like implementing with_untracked_task in terms with_task gets rather contrived. I had hoped that we would be able to do something like:

pub fn with_xxx_task<C, A, R, HCX>(&self,
                                   key: DepNode,
                                   cx: C,
                                   arg: A,
                                   task: fn(C, A) -> R)
                                   -> (R, DepNodeIndex) 
{
    self.with_task(key, cx, arg, |cx, arg| {
        // Explicitly add the read to the Krate node
        self.read(DepNode::Krate);

        // Execute the task without recording any other reads
        self.with_ignore(|| {
            task(cx, arg)
        })     
    })
}

But with_task takes a function, not a closure, so we cannot capture the task parameter. If you can come up with a way to make this work nonetheless, that'd be nice. Then you wouldn't even need to modify CurrentDepGraph and OpenTask. Otherwise I suggest to make a generalized, private version of with_task -- which allows to specify somehow which push and pop methods it will invoke -- and call that with different parameters from with_task and with_untracked_task.

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 18, 2017

Thanks for the review! What about something like "crate-wide query"? I'm also fine just changing it to "eval-always".

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 18, 2017

Yeah, let's stick to "eval-always". It's not a pretty name but it conveys the underlying concept well enough.

@wesleywiser wesleywiser force-pushed the wesleywiser:untracked_queries branch from 38b3aa5 to 9794bb5 Oct 21, 2017

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 21, 2017

@michaelwoerister I fixed up the commit per your feedback.

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 23, 2017

@wesleywiser Yes, that looks very good now! If you want to continue working on this, I suggest just appending to this PR.

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 25, 2017

@michaelwoerister Thanks! Pushed three new commits.

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 25, 2017

Looks very good!

I'm seeing this error on travis:

thread 'rustc' panicked at 'assertion failed: !data.colors.borrow().contains_key(&key)', /checkout/src/librustc/dep_graph/graph.rs:220:12

This suggests that we are re-running queries although they've already been marked as green. This is because we are not doing the whole try_mark_green_and_read() spiel for eval-always.

Thinking about it some more, there should really be no reason to treat an eval-always query different from a regular one, except for the changes you already implemented in graph.rs. So instead of modifying try_get(), could you just do if dep_node.is_eval_always() {...} in force()?:

profq_msg!(tcx, ProfileQueriesMsg::ProviderBegin);
let res = tcx.cycle_check(span, Query::$name(key), || {
tcx.sess.diagnostic().track_diagnostics(|| {
tcx.dep_graph.with_task(dep_node,
tcx,
key,
Self::compute_result)
})
})?;
profq_msg!(tcx, ProfileQueriesMsg::ProviderEnd);

That should also not introduce any code duplication.

Let me know if you have any questions about this change of strategy.

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 26, 2017

Hmmm... I can't seem to repro that. ./x.py test succeeds on my machine.

Regardless, I can certainly revert the changes to try_get_with() but I'm not entirely clear what you're proposing in regards to force(). Can you elaborate on that?

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 26, 2017

Hmmm... I can't seem to repro that. ./x.py test succeeds on my machine.

You are probably building with debug assertions disabled. I generally recommend setting debug-assertions = true in your config.toml. (and debuginfo-lines = true for better backtraces).

I imagine the updated force() method to look like this:

profq_msg!(tcx, ProfileQueriesMsg::ProviderBegin); 
let res = tcx.cycle_check(span, Query::$name(key), || { 
    tcx.sess.diagnostic().track_diagnostics(|| { 
        if dep_node.is_eval_always() {
            tcx.dep_graph.with_eval_always_task(dep_node, 
                                                tcx, 
                                                key, 
                                                Self::compute_result) 
        } else {
            tcx.dep_graph.with_task(dep_node, 
                                    tcx, 
                                    key, 
                                    Self::compute_result) 
        }
    }) 
})?; 
profq_msg!(tcx, ProfileQueriesMsg::ProviderEnd);

This way eval-always tasks are treated the same as regular with the only exception of what reads are recorded from them.

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 26, 2017

Oh got it. That makes sense.

I generally recommend setting debug-assertions = true in your config.toml. (and debuginfo-lines = true for better backtraces).

Thanks! I'll do that.

@wesleywiser wesleywiser force-pushed the wesleywiser:untracked_queries branch from 9e3be26 to 8281e88 Oct 26, 2017

@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 27, 2017

@wesleywiser wesleywiser changed the title [incremental] Add support for untracked queries [incremental] Add support for eval always queries Oct 27, 2017

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 27, 2017

Awesome, thank you so much @wesleywiser!

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Oct 27, 2017

📌 Commit 8281e88 has been approved by michaelwoerister

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Oct 27, 2017

⌛️ Testing commit 8281e88 with merge 51456a6...

bors added a commit that referenced this pull request Oct 27, 2017

Auto merge of #45353 - wesleywiser:untracked_queries, r=michaelwoerister
[incremental] Add support for eval always queries

Part of #45238
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Oct 27, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing 51456a6 to master...

@bors bors merged commit 8281e88 into rust-lang:master Oct 27, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@wesleywiser

This comment has been minimized.

Copy link
Member Author

wesleywiser commented Oct 27, 2017

Thanks for all the help @michaelwoerister!!

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Oct 27, 2017

You're welcome!

@wesleywiser wesleywiser deleted the wesleywiser:untracked_queries branch Oct 28, 2017

@mark-i-m mark-i-m referenced this pull request Jan 2, 2019

Merged

remove outdated comment #57290

pietroalbini added a commit to pietroalbini/rust that referenced this pull request Jan 7, 2019

Rollup merge of rust-lang#57290 - mark-i-m:remove-outdated-comment, r…
…=michaelwoerister

remove outdated comment

rust-lang#44234 was closed, apparently solved by rust-lang#45353

r? @michaelwoerister
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.