[clang-tools-extra] [clang-tidy] Add bugprone-smartptr-reset-ambiguous-call check (PR #121291)

Denis Mikhailov via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 20 15:56:20 PST 2025


================
@@ -0,0 +1,48 @@
+.. title:: clang-tidy - readability-ambiguous-smartptr-reset-call
+
+readability-ambiguous-smartptr-reset-call
+=========================================
+
+Finds potentially erroneous calls to ``reset`` method on smart pointers when
+the pointee type also has a ``reset`` method. Having a ``reset`` method in
+both classes makes it easy to accidentally make the pointer null when
+intending to reset the underlying object.
+
+.. code-block:: c++
+
+  struct Resettable {
+    void reset() { /* Own reset logic */ }
+  };
+
+  auto ptr = std::make_unique<Resettable>();
+
+  ptr->reset();  // Calls underlying reset method
+  ptr.reset();   // Makes the pointer null
+
+Both calls are valid C++ code, but the second one might not be what the
+developer intended, as it destroys the pointed-to object rather than resetting
+its state. It's easy to make such a typo because the difference between
+``.`` and ``->`` is really small.
+
+The recommended approach is to make the intent explicit by using either member
+access or direct assignment:
+
+.. code-block:: c++
+
+  std::unique_ptr<Resettable> ptr = std::make_unique<Resettable>();
+
+  (*ptr).reset();  // Clearly calls underlying reset method
+  ptr = nullptr;   // Clearly makes the pointer null
+
+The default smart pointers that are considered are ``std::unique_ptr``,
+``std::shared_ptr``, ``boost::unique_ptr``, ``boost::shared_ptr``. To specify
+other smart pointers or other classes use the :option:`SmartPointers` option.
+
+Options
+-------
+
+.. option:: SmartPointers
+
+    Semicolon-separated list of fully qualified class names of custom smart
+    pointers. Default value is `::std::unique_ptr;::std::shared_ptr;
----------------
denzor200 wrote:

> consider adding std::optional here also (even that is not smart ptr)

Strictly disagree with you, optional-like classes are not assignable with `nullptr`.
Here is no place for them in this check otherwise it will produce wrong fix hints:

```
{
  std::optional<Resettable> o;
  o.reset(); // should produce `o = std::nullopt;` but `o = nullptr;` does
}
{
  boost::optional<Resettable> o;
  o.reset(); // should produce `o = boost::none;` but `o = nullptr;` does
}

```

https://godbolt.org/z/YM79G8zdP


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


More information about the cfe-commits mailing list