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