[PATCH] unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter

[David Blaikie]

Hi lhames, rafael,

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.

http://reviews.llvm.org/D4876

Files:
  include/llvm/ADT/ScopeGuard.h
  include/llvm/Bitcode/ReaderWriter.h
  include/llvm/IR/GVMaterializer.h
  include/llvm/IR/Module.h
  lib/Bitcode/Reader/BitReader.cpp
  lib/Bitcode/Reader/BitcodeReader.cpp
  lib/Bitcode/Reader/BitcodeReader.h
  lib/IR/Module.cpp
  lib/IRReader/IRReader.cpp
  lib/LTO/LTOModule.cpp
  lib/Object/IRObjectFile.cpp
  unittests/Bitcode/BitReaderTest.cpp
  unittests/ExecutionEngine/JIT/JITTest.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D4876.12420.patch
Type: text/x-patch
Size: 17255 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140812/d27b96bb/attachment.bin>