Simplify event selection in TB diagnostics #2867
Conversation
I don't entirely understand what is going on here. Why does behavior change? And is this state transition even relevant for that example? Strongly deallocated items always prohibit deallocation no matter their state (right?), so it seems like listing the state transitions makes sense for |
Correct, that transition is not relevant at all to the error, which is why I hadn't noticed that it was missing. We have other transitions that are shown yet not useful, like |
|
That makes sense, but sounds orthogonal to this PR. And turns out |
| | | ||
| LL | drop(unsafe { Box::from_raw(raw) }); | ||
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| = help: this corresponds to an activation |
There was a problem hiding this comment.
What does "this corresponds to an activation" mean? This comment is more confusing than helpful I think.
|
There are functions in concurrency that contain 3 ranges in the same scope, I hope I didn't misinterpret the meaning of each. |
|
☔ The latest upstream changes (presumably #2876) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Oh also this is still marked as a draft. Did you even want another review? |
|
Okay, please squash this into one commit and then we can land this. :) |
|
Note that the comment you suggested on |
|
Ah, thanks for pointing that out! |
Vanille-N
force-pushed
the
tb-diags
branch
2 times, most recently
from
aa0fe7c to
a6505f3
Compare
Co-authored-by: Ralf Jung <post@ralfj.de>
|
@bors r+ |
|
☀️ Test successful - checks-actions |
TB diagnostics: avoid printing irrelevant events History contains some events that are relevant to the location but not useful to understand the error. We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error" This is also the occasion to fix #2867 (comment) [Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
TB diagnostics: avoid printing irrelevant events History contains some events that are relevant to the location but not useful to understand the error. We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error" This is also the occasion to fix rust-lang/miri#2867 (comment) [Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
TB diagnostics: avoid printing irrelevant events History contains some events that are relevant to the location but not useful to understand the error. We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error" This is also the occasion to fix rust-lang/miri#2867 (comment) [Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
TB diagnostics: avoid printing irrelevant events History contains some events that are relevant to the location but not useful to understand the error. We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error" This is also the occasion to fix rust-lang/miri#2867 (comment) [Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
As discussed previously, getting the range from
RangeMapcan make the filtering of events much simpler without any user-visible diff.See minor exception in <9d8fc00> and decide how to resolve it
help: deallocation counts as an implicit write? (Note: could be generalized to also includehelp: reborrow counts as an implicit read)