Add coherency check for query cycle breaking#153953
Add coherency check for query cycle breaking#153953zetanumbers wants to merge 2 commits intorust-lang:mainfrom
Conversation
|
I got 3 errors while running |
|
tests/ui/parallel-rustc/cycle_crash-issue-135870.rs Cycle diffPanic message |
|
tests/ui/parallel-rustc/ty-variance-issue-124423.rs Cycle diffPanic message |
|
tests/ui/parallel-rustc/ty-variance-issue-124423.rs Cycle diffPanic message |
|
UPDATE: This was issue with coherency check implementation |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Thanks for splitting this off from #153185, that makes reviewing much easier. A few comments below.
| if let Some(s) = self.opt_as_str() { | ||
| fmt::Debug::fmt(s, f) | ||
| } else { | ||
| fmt::Debug::fmt(&self.0, f) |
There was a problem hiding this comment.
This will just print a number, e.g. 123. Printing Symbol(123) would be much better.
There was a problem hiding this comment.
Symbols should never be used in contexts in which this path can be triggered, it's better to continue panicking here.
@zetanumbers In which specific context was this encountered?
There was a problem hiding this comment.
There was a problem hiding this comment.
Consult #t-compiler/parallel-rustc > Getting rid of the cycle detection thread
That thread doesn't have anything answering my question.
There was a problem hiding this comment.
This context is the cycle detection thread
There was a problem hiding this comment.
Could you add a comment explaining this use?
Using Symbols when the interner is dead is like using dangling pointers, suspicious at least.
If the cycle detection thread is the only such context and it's removed, then it would be better to remove this logic as well.
| if let Some(s) = self.opt_as_str() { | ||
| fmt::Display::fmt(s, f) | ||
| } else { | ||
| fmt::Debug::fmt(&self.0, f) |
compiler/rustc_query_impl/src/job.rs
Outdated
| { | ||
| if error != expected { | ||
| panic!( | ||
| "CycleError coherency check failed:\n expected: {expected:#?}\n got: {error:#?}" |
There was a problem hiding this comment.
Instead of "expected" and "got", would it be better to indicate the single-threaded result and the multi-threaded result? It's conceivable that the single-threaded one might be wrong.
There was a problem hiding this comment.
Also, does "coherency" have a particular meaning. It makes me think of trait coherency, which is unrelated. "Consistency" might be better, it doesn't have a Rust-specific meaning, e.g. "inconsistent query cycle detection: ...".
| .collect(), | ||
| }; | ||
|
|
||
| if cfg!(debug_assertions) |
There was a problem hiding this comment.
There are no added comments in this commit. An explanatory comment here would be useful. Something like "compare the single-threaded cycle detection against the multi-threaded cycle detection".
|
Also, presumably we can't land this PR as is due to the test failures. I assume the idea is to show the existing bug, and that prompts other fixes? |
| impl fmt::Debug for Symbol { | ||
| fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { | ||
| fmt::Debug::fmt(self.as_str(), f) | ||
| if let Some(s) = self.opt_as_str() { |
There was a problem hiding this comment.
| if let Some(s) = self.opt_as_str() { | |
| if are_session_globals_set() { |
Together with a comment #153953 (comment) explaining why it's acceptable.
opt_as_str can be removed, it shouldn't be a generally available method.
|
The main problem with this PR would be that it tests for a property we do not have, which means it's effectively just adding unnecessary panics. It's also unclear to me if the use of |
|
☔ The latest upstream changes (presumably #154032) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I ground my changes in improvements to observable consistency between single-threaded and multi-threaded runs of "cycle detected" tests for which I compare those runs' outputs. It's WIP right now, so this isn't yet the final version.
Why don't we have this property? Isn't it possible to add such a property? Or are you saying we shouldn't try doing this change?
Could you elaborate on which assumptions you are talking about? |
With
debug_assertionscompare if generatedCycleErrors differ between single-threaded and multi-threaded versions of query cycle breaking code and panic if so.I reasonably assume multi-threaded cycle breaking prioritizes breaking single-threaded cycles. I've made
find_cycle_in_stackto be a fallible function, always finding single-threaded cycle if there is any relative to the query argument.There are also some changes to Symbol's Debug and Display impls to make those panic less.
Split from #153185.
r? @nnethercote
cc @Zoxc