Remove Drop impl of mpsc Receiver and (Sync)Sender

[benschulz]

This change removes the empty Drop implementations for mpsc::Receiver, mpsc::Sender and mpsc::SyncSender. These implementations do not specify #[may_dangle], so by removing them we make mpsc types play nice with drop check.

This was previously attempted in #105243 but then abandoned due to a test failure. I've aligned the test with those for Mutex and RwLock.

[rustbot]

r? @joshtriplett

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

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit a38ea96 has been approved by dtolnay

It is now in the queue for this repository.

[bors]

⌛ Testing commit a38ea96 with merge 4ce79c4...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[steffahn]

It seems like the expressed motivation mentioned here

#93563 (comment)

on why these Drop impls still existed was that some user might require you can use a type such as T = mpsc::Receiver<()> for a function like fn f<T: Drop>() {}. Of course, T: Drop bounds are pretty dumb, and maybe that's accepted breakage (I haven't looked at the guidelines on semver in Rust to find out more about removal of Drop implementations) or maybe it's easy to determine that this is non-existent breakage in crater. But I did want to mention it here nonetheless.

[benschulz]

@steffahn, that point was raised in the PR linked above and deemed a non-issue, see #105243 (comment) ff.

That notwithstanding, I'm happy to file a PR that restores the Drop implementations with #[may_dangle] attributes. Just say the word. :)

[steffahn]

Thanks for the link. I don't think they should be kept for to address this breakage. I believe it's very very unlikely someone would "rely" on this in the first place, and even then it'd likely not be very reasonable code to begin with. I just wanted it mentioned on this PR for context 😇. And also I was curious if perhaps removal of Drop is already "officially" accepted breakage anyways, or else I'm considering starting a discussion to make it officially acceptable.

[steffahn]

Sorry for posting so many things here - as far as I can tell the contained mpmc::Sender/Receiver types still have an ordinary Drop implementation, so I'm questioning whether this PR actually changed anything to begin with, regarding drop check. I'm on a phone right now, so it's hard to verify this conclusively.

Even if it does make us accept code the was previously not accepted, there certainly is a lack of test for that, as this PR does not introduce any new tests.

[benschulz]

Sorry for posting so many things here

No worries, I want to get this right. :)

as far as I can tell the contained mpmc::Sender/Receiver types still have an ordinary Drop implementation

The nightly documentation shows no such implementation, but the stable documentation does. Perhaps I'm misunderstanding your point?

Even if it does make us accept code the was previously not accepted, there certainly is a lack of test for that, as this PR does not introduce any new tests.

It's implicitly tested by the changed test, but I think you raise a good point in that there is no test whose sole purpose is to test that. I'll try to find the time to file a PR for it.

[dtolnay]

I was curious if perhaps removal of Drop is already "officially" accepted breakage anyways, or else I'm considering starting a discussion to make it officially acceptable.

Please do. I am confident that the standard library team would be open to this.