[patch] Pass a MemoryBufferRef when we can avoid taking ownership

[Rafael Espíndola]

On 26 August 2014 14:30, David Blaikie <dblaikie at gmail.com> wrote:
> This patch essentially supercedes one I sent out for review a few
> weeks ago? (that had to play games with ownership/unique_ptrs around
> these functions due to the split ownership, etc) and takes the stance
> of "construct a new shallow MemoryBuffer rather than lying to 'share'
> unique ownership"?

More or less. From my point of view the stance is that the interface
should have the type that more directly corresponds to the interface
semantics, not its implementation. For example

* parseAssembly: without this patch it takes a MemoryBuffer to pass to
a SourceMgr, but the fact that uses a SourceMgr should be an
implementation detail and not change the interface.
* parseBitcodeFile: It takes a MemoryBuffer because it is implemented
on top of getLazyBitcodeModuleImpl, but that is also an implementation
detail. We could have a separate non-lazy code path in the reader for
example.

> Might be worth changing getLazyBitcodeModuleImpl to take a
> unique_ptr<MemoryBuffer>&& before you commit this patch? (that way you
> don't have to play games with get/release after the successful call)

You mean "unique_ptr<MemoryBuffer>&", right? It actually looks easier
to do that after my patch. I attached a followup patch.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 8234 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140826/edd90021/attachment.bin>