Uplift clippy::{drop,forget}_{ref,copy} lints

[Urgau]

This PR aims at uplifting the clippy::drop_ref, clippy::drop_copy, clippy::forget_ref and clippy::forget_copy lints.

Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.

drop_ref and forget_ref

ℹ️ The lints have been renamed to dropping_copy_types and forgetting_copy_types in #111756

The drop_ref and forget_ref lint checks for calls to std::mem::drop or std::mem::forget with a reference instead of an owned value.

Example

let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();

Explanation

Calling drop or forget on a reference will only drop the reference itself, which is a no-op. It will not call the drop or forget method on the underlying referenced value, which is likely what was intended.

drop_copy and forget_copy

ℹ️ The lints have been renamed to dropping_references and forgetting_references in #111756

The drop_copy and forget_copy lint checks for calls to std::mem::forget or std::mem::drop with a value that derives the Copy trait.

Example

let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
                    // original unaffected

Explanation

Calling std::mem::forget does nothing for types that implement Copy since the value will be copied and moved into the function on invocation.

---

Followed the instructions for uplift a clippy describe here: #99696 (review)

cc @m-ou-se (as T-libs-api leader because the uplifting was discussed in a recent meeting)

[rustbot]

r? @TaKO8Ki

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Noratrieb]

some cases in rustc, fun (can't wait for clippy to finally work on rustc^^)

[Urgau]

Nominating for T-lang approval, as it seems to be the norm.

@rustbot label: +I-lang-nominated

[nikomatsakis]

@rustbot labels -I-lang-nominated

@rfcbot fcp merge

We discussed this our @rust-lang/lang meeting and we agree that, when this occurs, it is very likely to be a bug or misunderstanding, which is our usual criteria for uplift.

[Urgau]

@jethrogb @raoulstrackx Any objection to landing this with drop(entry_guard) instead of drop(entry) ?

I've confirm in an earlier CI build that the code at least compile.

[jethrogb]

@raoulstrackx what do you think of this change (compared to master)

diff --git a/library/std/src/sys/sgx/waitqueue/mod.rs b/library/std/src/sys/sgx/waitqueue/mod.rs
index 61bb11d9a6f..3e3caa0d00f 100644
--- a/library/std/src/sys/sgx/waitqueue/mod.rs
+++ b/library/std/src/sys/sgx/waitqueue/mod.rs
@@ -202,12 +202,18 @@ pub fn wait_timeout<T, F: FnOnce()>(
     pub fn notify_one<T>(
         mut guard: SpinMutexGuard<'_, WaitVariable<T>>,
     ) -> Result<WaitGuard<'_, T>, SpinMutexGuard<'_, WaitVariable<T>>> {
+        // SAFETY: lifetime of the pop() return value is limited to the map
+        // closure (The closure return value is 'static). The underlying
+        // stack frame won't be freed until after the WaitGuard created below
+        // is dropped.
         unsafe {
-            if let Some(entry) = guard.queue.inner.pop() {
+            let tcs = guard.queue.inner.pop().map(|entry| -> Tcs {
                 let mut entry_guard = entry.lock();
-                let tcs = entry_guard.tcs;
                 entry_guard.wake = true;
-                drop(entry);
+                entry_guard.tcs
+            });
+
+            if let Some(tcs) = tcs {
                 Ok(WaitGuard { mutex_guard: Some(guard), notified_tcs: NotifiedTcs::Single(tcs) })
             } else {
                 Err(guard)
@@ -223,6 +229,9 @@ pub fn notify_one<T>(
     pub fn notify_all<T>(
         mut guard: SpinMutexGuard<'_, WaitVariable<T>>,
     ) -> Result<WaitGuard<'_, T>, SpinMutexGuard<'_, WaitVariable<T>>> {
+        // SAFETY: lifetime of the pop() return values are limited to the
+        // while loop body. The underlying stack frames won't be freed until
+        // after the WaitGuard created below is dropped.
         unsafe {
             let mut count = 0;
             while let Some(entry) = guard.queue.inner.pop() {
@@ -230,6 +239,7 @@ pub fn notify_all<T>(
                 let mut entry_guard = entry.lock();
                 entry_guard.wake = true;
             }
+
             if let Some(count) = NonZeroUsize::new(count) {
                 Ok(WaitGuard { mutex_guard: Some(guard), notified_tcs: NotifiedTcs::All { count } })
             } else {

[raoulstrackx]

Yes I think that's an improvement!

[Urgau]

Alright, I've fixed two other compilation issues: a Redox one (just had to replace the drop by let _ =) and a SGX one (see the discussion above for the changes).

@rustbot ready

[GuillaumeGomez]

@bors r=davidtwco

[bors]

📌 Commit f5aede9 has been approved by davidtwco

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

[bors]

⌛ Testing commit f5aede9 with merge 077fc26...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 077fc26 to master...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 077fc26 to master...

[rust-timer]

Finished benchmarking commit (077fc26): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.8%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-1.9%, -1.0%]	4
All ❌✅ (primary)	0.5%	[0.4%, 0.8%]	5

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.7%, 1.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.9%, -2.4%]	2
All ❌✅ (primary)	1.2%	[0.7%, 1.6%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 659.774s -> 659.596s (-0.03%)