[PATCH] D50883: [clang-tidy] Handle unique owning smart pointers in ExprMutationAnalyzer

[Shuai Wang via Phabricator via cfe-commits]

shuaiwang added a comment.

In https://reviews.llvm.org/D50883#1229297, @JonasToth wrote:

> >   Different from std::vector::operator[] which has two overloads for const and non-const access, std::unique_ptr only has one const version of `operator->`.
> > 
> > So for SmartPtr x; x->mf(); we only see a const operator being invoked on x. mf is not a member of SmartPtr and the member call to mf is not on x directly, we never followed that far.
>
> I think the `operator->` is transitively called, isn't it? (see andrei alexandrescu talk here: https://youtu.be/ozOgzlxIsdg?t=15m55s where he gives a nice class for generic locking)
>  Maybe there is something more general at work? I think @aaron.ballman knows more about deeper language questions :)


Right, for `x->mf()` (where `x` is some kind of smart pointer), `operator->` is invoked on the smart pointer itself, and then that yields a (real) pointer, in which case the `operator->` magically reappears and is applied on the real pointer.
For now we're basically treating `SmartPtr::operator->()` the same as "taking the address of `Exp`", which is treated as immediately mutating `Exp`. The benefit of this approach is: when we're able to do `findPointeeMutation`, we'll be able to further follow the pointer and see whether the pointee is mutated, and we'll be able to distinguish between these two cases:

  struct Foo {
  void mf();
  void cmf() const;
  };
  std::unique_ptr<Foo> p;
  p->mf(); // mutates Foo
  p->cmf(); // doesn't mutate Foo, but is treated as mutation for now. Can be improved when we're able to do findPointeeMutation( <pointer returned by operator->() call on p> )


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D50883