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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
