[PATCH] D86373: [analyzer] Add modeling for unique_ptr move constructor

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

This is easier than D86293 <https://reviews.llvm.org/D86293> because there's no old value in the freshly constructed smart pointer, right? I suspect that you can still re-use a lot of the implementation with D86293 <https://reviews.llvm.org/D86293>, at least partially.



================
Comment at: clang/test/Analysis/smart-ptr.cpp:295
+  P->foo();  // No warning.
+}
----------------
vrnithinkumar wrote:
> I was trying to test the below code.
> ```
> void foo_() {
>   std::unique_ptr<A> PToMove;
>   std::unique_ptr<A>&& AfterRValeRefCast = std::move(functionReturnsRValueRef());
>   std::unique_ptr<A> P(AfterRValeRefCast);
>   P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
> }
> ```
> 
> But passing the local RValue reference variable to move constructor is always invoking the deleted copy constructor.
Yeah, you still need an explicit move over it. Implicit moves don't happen because it's an rvalue reference, it has more to do with the anonymity of the object; the compiler only auto-moves when there's no possibility for accidental implicit use-after-move, and in presence of a named reference to the value, accidental implicit use-after-move is still very much possible, so an explicit move is required. That's not the exact rules but that's, as far as i understand, the logic behind the exact rules.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86373/new/

https://reviews.llvm.org/D86373