NoQ added a comment. > Well some of them are exactly the same type as the `Lame` class example > above. Like: > `simbody/report-TestArray.cpp-testMoveConstructionAndAssignment-27-1.html#EndPath`. > (So the incomplete modelling of the destructor is at least one cause. The > other reason that you suggested might as well be true).
The problem with the `Lame` class above was the constructor in `make_unique`, not the destructor. But more importantly, in this case the destructor most likely isn't responsible for freeing memory. The `push_back()` method most likely *moves* the smart pointer into the array, so by the time `~unique_ptr()` hits the smart pointer is already empty, there's nothing to free. What we're missing is a "pointer escape" event for the raw pointer. It sounds like a feature we have to implement: when the smart pointer region pointer-escapes (in this case, due to being passed into an unknown function via rvalue reference), the raw pointer region should also pointer-escape. (Or, if `push_back()` is inlined then there's a different reason for escape, something along the lines of getting move-assigned into the heap, which we should probably also implement separately!). Damn, that's an interesting can of worms. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105821/new/ https://reviews.llvm.org/D105821 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
