[clang-tools-extra] Add bugprone-loop-variable-copied-then-modified clang-tidy check. (PR #157213)

Nicolas van Kempen via cfe-commits cfe-commits at lists.llvm.org
Tue Sep 9 20:03:16 PDT 2025


================
@@ -0,0 +1,48 @@
+.. title:: clang-tidy - bugprone-loop-variable-copied-then-modified
+
+bugprone-loop-variable-copied-then-modified
+===========================================
+
+Detects when a loop variable is copied and then subsequently modified and
+suggests replacing with a ``const`` reference or an explicit copy.
+
+This pattern is considered bugprone because, frequently, programmers do not
+realize that they are modifying a *copy* rather than an underlying value,
+resulting in subtly erroneous code.
+
+For instance, the following code attempts to null out a value in a map, but only
+succeeds in 
+
+.. code-block:: c++
+
+  for (auto target : target_map) {
+    target.value = nullptr;
+  }
+
+The programmer is likely to have intended this code instead:
+
+.. code-block:: c++
+    
+  for (const auto& target : target_map) {
+    target.value = nullptr;
+  }
+
+This warning can be suppressed in one of two ways:
+  - In cases where the programmer did not intend to create a copy, they can
+    convert the loop variable to a ``const`` reference. A FixIt message will
+    provide a naive suggestion of how to achieve this, which works in most
+    cases.
+  - In cases where the intent is in fact to modify a copy, they may perform the
+    copy inside the body of the loop, and perform whatever operations they like
+    on that copy.
----------------
nicovank wrote:

Is this actually better and/or more readable than having the copy as the loop variable? I'm leaning towards no. Which is also a problem with suggesting that in the diagnostic.

https://github.com/llvm/llvm-project/pull/157213


More information about the cfe-commits mailing list