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

Make try_mark_previous_green aware of cycles. #66846

Merged
merged 1 commit into from
Dec 6, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 16 additions & 5 deletions src/librustc/dep_graph/graph.rs
Original file line number Diff line number Diff line change
Expand Up @@ -710,14 +710,25 @@ impl DepGraph {
return None
}
None => {
if !tcx.sess.has_errors() {
if !tcx.sess.has_errors_or_delayed_span_bugs() {
bug!("try_mark_previous_green() - Forcing the DepNode \
should have set its color")
} else {
// If the query we just forced has resulted
// in some kind of compilation error, we
// don't expect that the corresponding
Copy link
Contributor Author

Choose a reason for hiding this comment

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

TBH I do not grasp the reasons of this expectation.
But whatever they are, seems the test is a counter-example?

Copy link
Member

Choose a reason for hiding this comment

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

The comment should be re-worded to "If the query we just forced has resulted in some kind of compilation error, we cannot rely on the dep-node color having been properly updated."

Copy link
Member

Choose a reason for hiding this comment

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

To elaborate: Forcing a query (as we have done when reaching this point in the code) must update the colors table with an entry for that query invocation. Reaching the None branch here means that we did not find the expected entry in the table, so we abort compilation with the bug!. However, there seem to be cases when something generated an error while forcing the query where table is not updated. This is supposedly harmless (although it would be great to find out how that happens exactly) because once an error has occurred we don't persist anything to the incremental cache.

So the comment should expanded to something like:

// If the query we just forced has resulted in 
// some kind of compilation error, we cannot rely on
// the dep-node color having been properly updated.
// This means that the query system has reached an
// invalid state. We let the compiler continue (by
// returning `None`) so it can emit error messages
// and wind down, but rely on the fact that this
// invalid state will not be persisted to the 
// incremental compilation cache because of 
// compilation errors being present.

Copy link
Member

Choose a reason for hiding this comment

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

Also, the new behavior of returning instead of continuing marking is definitely an improvement!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, that makes sense now!

// dep-node color has been updated.
// If the query we just forced has resulted in
// some kind of compilation error, we cannot rely on
// the dep-node color having been properly updated.
// This means that the query system has reached an
// invalid state. We let the compiler continue (by
// returning `None`) so it can emit error messages
// and wind down, but rely on the fact that this
// invalid state will not be persisted to the
// incremental compilation cache because of
// compilation errors being present.
debug!("try_mark_previous_green({:?}) - END - \
dependency {:?} resulted in compilation error",
dep_node,
dep_dep_node);
return None
}
}
}
Expand Down
15 changes: 15 additions & 0 deletions src/test/incremental/issue-61323.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
// revisions: rpass cfail

enum A {
//[cfail]~^ ERROR 3:1: 3:7: recursive type `A` has infinite size [E0072]
B(C),
}

#[cfg(rpass)]
struct C(Box<A>);

#[cfg(cfail)]
struct C(A);
//[cfail]~^ ERROR 12:1: 12:13: recursive type `C` has infinite size [E0072]

fn main() {}