tests: basic-[debugger-]stepping.rs: Disable SingleUseConsts MIR pass temporarily #147426
Conversation
To make more of the test pass. It should not be necessary to disable this pass, but by doing it we can avoid further regressions while we figure out how to solve this use case properly. The last two `FIXME(33013)` didn't go away from this change, only the first six. But that can be investigated separately.
rustbot
added
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use |
This comment has been minimized.
This comment has been minimized.
Enselic
force-pushed
the
better-stepping
branch
from
b0564e3 to
5b47948
Compare
|
r? @saethlin I'm personally dubious on disabling MIR passes in debuginfo tests... but I don't have the context here to really evaluate the tradeoffs. |
|
If we don't disable the pass, we can get other accidental regressions. If we disable the pass we at least know the situation will not get worse. And that risk of additional regressions is high since it already happened at least twice in the past. Long term we should do a proper fix of course. Edit to avoid pinging people: You are right. We need to test both with and without SingleUseConsts to meaningfully prevent regressions. For that we need support for revisions, which I will look into adding now. |
|
I'm very confused by the way you are describing this. If there are actual regressions happening in the behavior of the compiler, then what this PR does doesn't fix them. All it does is make sure the test suite keeps passing, which would make it easier for us to ship a regression. |
saethlin
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #146414) made this pull request unmergeable. Please resolve the merge conflicts. |
5 participants
To make more of the test pass. It should not be necessary to disable this pass, but by doing it we can avoid further regressions while we figure out how to solve this use case properly.
We know this use case is sensitive to regressions because it already happened at least once. See #33013 (comment).
CC #130896
The last two
FIXME(#33013)go away with #147462 in a completely different way (there will be trivial conflicts for me to resolve in basic-stepping.rs when one of them lands, but that's fine.)