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

[Rafael Espíndola]

> Though the same argument applies to "getBitcodeTargetTriple" I assume
> - which could be changed similarly. That was one of the comments I
> made in the original review: "one possible option would be to create
> new
> shallow MemoryBuffers in these cases".

Yes, I think it should take a StringRef too.

>> It is an
>> implementation detail that internally that is implemented on top of
>> the lazy interface that has a more complicated ownership rules.
>
> Well, not entirely an implementation detail. It's relevant to the user
> that the Module doesn't just read from that StringRef on construction
> - it's lazy, it keeps a reference to that memory and reads from it
> arbitrarily later when the Module operations are used.

It is an implementation detail in the particular case of
parseBitcodeFile. From the caller, these two implementations would
look the same

* Call the getLazyBitcodeModuleImpl. Do a dance to make sure it never
owns buffer and force it to read everything before returning
(materializeAllPermanently).
* Have a separate custom implementation that doesn't use the lazy reading.

> Which ones do you have in mind? I'd like to get a good sense of what's
> done where/why, if there are existing idioms that we want to promote
> to be the preferred solutions, etc.

There is the triple extraction one you noticed. There is
ParseAssembly. The big one is my patch for lib/Object :-)

>> Doesn't look like it,
>
> Curious - how can/did you tell?

So far I have only run the tests. But in any case, a use would have
come before the call to materializeAllPermanently, so it should be
possible to do a more complete check.

>> but if needed I think it should still be two StringRefs.
>
> Two StringRefs even rather than your MemoryBufferRef? What do you see
> as the distinction between the use of each of those, if any?

Once we have something like MemoryBufferRef that would be the natural choice.

Cheers,
Rafael