This turned out to be a bit tricky as there are some callers doing
strange things with ownership of the this MemoryBuffer.
A couple of callers (llvm::getBitcodeTargetTriple,
llvm::parseBitcodeFile) don't take ownership of the MemoryBuffer, but
still want to construct a Module (but they either ensure it's fully
materialized, or otherwise destroy it before the function is over, being
sure to take the MemoryBuffer back from the Module so it is not
destroyed). Some of these callers were adjusted to use ScopeGuards to
ensure the release of a fake local unique_ptr, others were able to be
adjusted to pass ownership transiently, then take it back again later.
Other ideas are welcome - one possible option would be to create new
shallow MemoryBuffers in these cases. Another would be to make these
data structures consistently non-owning, though that sounds difficult
for other users. I'd like to throw a few ideas around here because I
think this pattern shows up a few times in LLVM - where an API has
multiple users, some of whom want to give ownership, some of whom don't.
I'd like to figure out a good/consistent/simple answer for when we come
across this again.
What's the point of this? All std::move does is cast to T&&. You already have a T&&.