From 70168e8e61c352f6f37675849b0bf5b4a644ad22 Mon Sep 17 00:00:00 2001
From: "github-actions[bot]"
 <41898282+github-actions[bot]@users.noreply.github.com>
Date: Wed, 19 Mar 2025 14:10:35 +0000
Subject: [PATCH] Create rule S7450 Synchronization locks should not be dropped
 immediately after acquisition (#4794)

* Create rule S7450

* Update metadata.json

* Update rule.adoc

* Update rule.adoc

* Update metadata.json

---------

Co-authored-by: sallaigy <sallaigy@users.noreply.github.com>
Co-authored-by: Gyula Sallai <gyula.sallai@sonarsource.com>
---
 rules/S7450/metadata.json      |  2 ++
 rules/S7450/rust/metadata.json | 24 ++++++++++++++++++++++++
 rules/S7450/rust/rule.adoc     | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 58 insertions(+)
 create mode 100644 rules/S7450/metadata.json
 create mode 100644 rules/S7450/rust/metadata.json
 create mode 100644 rules/S7450/rust/rule.adoc

diff --git a/rules/S7450/metadata.json b/rules/S7450/metadata.json
new file mode 100644
index 0000000000..2c63c08510
--- /dev/null
+++ b/rules/S7450/metadata.json
@@ -0,0 +1,2 @@
+{
+}
diff --git a/rules/S7450/rust/metadata.json b/rules/S7450/rust/metadata.json
new file mode 100644
index 0000000000..d1c30183f5
--- /dev/null
+++ b/rules/S7450/rust/metadata.json
@@ -0,0 +1,24 @@
+{
+  "title": "Synchronization locks should not be dropped immediately after acquisition",
+  "type": "BUG",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant\/Issue",
+    "constantCost": "5min"
+  },
+  "tags": [
+    "clippy"
+  ],
+  "defaultSeverity": "Major",
+  "ruleSpecification": "RSPEC-7450",
+  "sqKey": "S7450",
+  "scope": "All",
+  "defaultQualityProfiles": ["Sonar way"],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "HIGH"
+    },
+    "attribute": "LOGICAL"
+  }
+}
diff --git a/rules/S7450/rust/rule.adoc b/rules/S7450/rust/rule.adoc
new file mode 100644
index 0000000000..6c6d102813
--- /dev/null
+++ b/rules/S7450/rust/rule.adoc
@@ -0,0 +1,32 @@
+
+== Why is this an issue?
+Immediately dropping a synchronization lock (e.g., `mutex`, `rwlock`) after acquiring it using `let _ = sync_lock` is often unintentional and can lead to subtle bugs. By extending the lock lifetime to the end of the scope using a named variable, the code becomes safer and intentions are clearer. If immediate drop is intended, using `std::mem::drop` conveys the intention more clearly and reduces error-prone behavior.
+
+
+=== Code examples
+
+==== Noncompliant code example
+[source,rust,diff-id=1,diff-type=noncompliant]
+----
+let _ = Mutex::new(1).lock(); // Noncompliant: Immediately drops the lock.
+----
+
+==== Compliant solution
+
+[source,rust,diff-id=1,diff-type=compliant]
+----
+// Extend lock lifetime to end of scope
+let _lock = Mutex::new(1).lock(); // Compliant: Lock remains till scope ends.
+----
+
+You can also explicitly drop the lock to convey intention:
+
+[source,rust,diff-id=1,diff-type=compliant]
+----
+std::mem::drop(Mutex::new(1).lock()); // Compliant: Clearly drops the lock.
+----
+
+== Resources
+=== Documentation
+
+* Clippy Lints - https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_lock