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

Conversation

@gizmondo
Copy link
Contributor

gizmondo commented Nov 28, 2019

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Nov 28, 2019

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @michaelwoerister (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

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

This comment has been minimized.

Copy link
@gizmondo

gizmondo Nov 28, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@michaelwoerister

michaelwoerister Dec 6, 2019

Contributor

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."

This comment has been minimized.

Copy link
@michaelwoerister

michaelwoerister Dec 6, 2019

Contributor

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.

This comment has been minimized.

Copy link
@michaelwoerister

michaelwoerister Dec 6, 2019

Contributor

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

This comment has been minimized.

Copy link
@gizmondo

gizmondo Dec 6, 2019

Author Contributor

Thanks, that makes sense now!

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Nov 29, 2019

Thanks for the PR, @gizmondo! I should be able to take a closer look next week.

@JohnCSimon

This comment has been minimized.

Copy link
Member

JohnCSimon commented Dec 6, 2019

ping from triage:
@michaelwoerister - Hi! Can you look at this PR?

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Dec 6, 2019

@gizmondo If you update the comment as suggested, I'm happy to r+ this.

@gizmondo gizmondo force-pushed the gizmondo:master branch from bb6e613 to de255a9 Dec 6, 2019
@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Dec 6, 2019

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 6, 2019

📌 Commit de255a9 has been approved by michaelwoerister

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 6, 2019

⌛️ Testing commit de255a9 with merge a1d84a0...

bors added a commit that referenced this pull request Dec 6, 2019
Make try_mark_previous_green aware of cycles.

Fixes #61323

r? @michaelwoerister
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Dec 6, 2019
Make try_mark_previous_green aware of cycles.

Fixes rust-lang#61323

r? @michaelwoerister
@JohnTitor

This comment has been minimized.

Copy link
Member

JohnTitor commented Dec 6, 2019

@bors retry rolled up

bors added a commit that referenced this pull request Dec 6, 2019
Rollup of 11 pull requests

Successful merges:

 - #66846 (Make try_mark_previous_green aware of cycles.)
 - #66959 (Remove potential cfgs duplicates)
 - #66988 (Fix angle bracket formatting when dumping MIR debug vars)
 - #66998 (Modified the testcases for VxWorks)
 - #67008 (rustdoc: Add test for fixed issue)
 - #67023 (SGX: Fix target linker used by bootstrap)
 - #67033 (Migrate to LLVM{Get,Set}ValueName2)
 - #67049 (Simplify {IoSlice, IoSliceMut}::advance examples and tests)
 - #67054 (codegen "unreachable" for invalid SetDiscriminant)
 - #67081 (Fix Query type docs)
 - #67085 (Remove boxed closures in address parser.)

Failed merges:

r? @ghost
@bors bors merged commit de255a9 into rust-lang:master Dec 6, 2019
4 of 5 checks passed
4 of 5 checks passed
homu Testing commit de255a9163963e62a06c981b71041f071058ec5b with merge a1d84a0c2517186b85cc2a6a6984cb8ec92c4954...
Details
pr #20191206.13 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-7) Linux x86_64-gnu-llvm-7 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.