[significant_drop_tightening] Add #11125 test

[c410-f3r]

Fix #11125

---

changelog: none

[rustbot]

r? @xFrednet

(rustbot has picked a reviewer for you, use r? to override)

[xFrednet]

r% @blyxyas

(xFrednet has picked a reviewer for you, use r% to override)

[blyxyas]

Could you simplify this? We only need sender_wakers (or a Mutex<Vec<Waker>>), the test doesn't need a lot of the original block to still be effective (e.g. the initial if stmt. or SendValue)

[c410-f3r]

Is it really necessary to trim-down a self-contained use-case provided by a user of this lint?

[blyxyas]

If #11128 fixed the initial problem with #11125 and the current CI (checking for the 100% faithful usecase) is successful, I think we can simplify it. Future-proofing each PR merged by adding the real usecase that caused the problem isn't something viable.

[c410-f3r]

I see. Thank you

[blyxyas]

But looking at the current tests/ui/significant_drop_tightening.rs, it seems like a simplified test was provided in #11129. I'm not sure how to proceed here.

[xFrednet]

But looking at the current tests/ui/significant_drop_tightening.rs, it seems like a simplified test was provided in #11129. I'm not sure how to proceed here.

Is my understanding correct, that this PR only adds a test and that a simpler example of the same problem has been added in #11129?

If this test doesn't check a different behavior or variant of one, I'd suggest closing the PR. If it's a variant, that checks something slightly different, it would be good to merge it. Merging it either way would not be wrong :)

[bors]

☔ The latest upstream changes (presumably #11161) made this pull request unmergeable. Please resolve the merge conflicts.

[blyxyas]

Well, I think we'll do an exception this time. @c410-f3r, could you fix the conflicting files? 🤠

[blyxyas]

just a little mini-ping
@c410-f3r

[c410-f3r]

Thank you for the heads-up.

Unfortunately, I don't have the motivation to continue pursuing this issue.