[clang-tidy] Check request: don't use `reset` for a smart pointer to Resetable

[denzor200]

Assume we have a user-defined type A:

struct A {
    void reset() { /* A's own logic to reset something */ }
};

And then this type was instantiated using std::unique_ptr (std::shared_ptr also acceptable):

auto a = std::make_unique<A>();

Since both std::unique_ptr and A have reset method with different meaning, it might be ambiguous to use them:

a->reset(); // performs the logic defined in A, "a" stays alive
a.reset();  // "a" becomes nullptr

It might be surprised for a programmer to call not the reset he expects(more over it might be bugproned), and it's easy to make such typo because the difference between . and -> really small.
Suppose the code above might be changed in a better(more clear) way:

a.get()->reset(); // performs the logic defined in A, "a" stays alive
a = nullptr; // "a" becomes nullptr

[vbvictor]

I would love to take this issue. It's my first time contributing to llvm.
@denzor200, Could you assign it to me?

[denzor200]

@EugeneZelenko could you please assign this issue to @vbvictor ? Since I don't have a rights to assign it.

[denzor200]

It will have a conflict with redundant-smartptr-get: https://clang.llvm.org/extra/clang-tidy/checks/readability/redundant-smartptr-get.html

[denzor200]

The way to change provided sample with no conflict might look like this:

auto* a_raw = a.get();
a_raw->reset(); // performs the logic defined in A, "a" stays alive
a = nullptr; // "a" becomes nullptr

[vbvictor]

Oppened pr for this issue #121291
Could not find a way to link issue with pr

[denzor200]

The same issue with std::optional it's not a smart pointer, but it has pointer-like interface and also has reset method:
https://en.cppreference.com/w/cpp/utility/optional/operator*
https://en.cppreference.com/w/cpp/utility/optional/reset