Commit Graph

7 Commits

Author SHA1 Message Date
David Blaikie
38a4f3bbec Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.
An unpleasant surprise while migrating unique_ptrs (see changes in
lib/Object): ErrorOr<int*> was implicitly convertible to
ErrorOr<std::unique_ptr<int>>.

Keep the explicit conversions otherwise it's a pain to convert
ErrorOr<int*> to ErrorOr<std::unique_ptr<int>>.

I'm not sure if there should be more SFINAE on those explicit ctors (I
could check if !is_convertible && is_constructible, but since the ctor
has to be called explicitly I don't think there's any need to disable
them when !is_constructible - they'll just fail anyway. It's the
converting ctors that can create interesting ambiguities without proper
SFINAE). I had to SFINAE the explicit ones because otherwise they'd be
ambiguous with the implicit ones in an explicit context, so far as I
could tell.

The converting assignment operators seemed unnecessary (and similarly
buggy/dangerous) - just rely on the converting ctors to convert to the
right type for assignment instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217048 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03 17:31:25 +00:00
Rafael Espindola
548f2b6e8f Don't own the buffer in object::Binary.
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
  This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
  for convenience functions that take a filename and return both the
  buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:44:46 +00:00
Rafael Espindola
79002da926 Use std::unique_ptr to make the ownership explicit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214377 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-31 03:12:45 +00:00
Rafael Espindola
0d50598d71 Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.
Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211595 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-24 13:56:32 +00:00
Rafael Espindola
b138caba43 Pass a std::unique_ptr& to the create??? methods is lib/Object.
This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211546 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 22:00:37 +00:00
Rafael Espindola
1f659329b6 Make ObjectFile and BitcodeReader always own the MemoryBuffer.
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.

Overall this looks like a more efficient and less brittle api.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211542 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-23 21:53:12 +00:00
Rafael Espindola
91f86b7e1c Add a SymbolicFile interface between Binary and ObjectFile.
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.

Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-21 20:10:59 +00:00