this is the last of them in my build of LLVM. Haven't tried Clang yet.

Found via UBSan.

llvm-svn: 243934

Apparently, the style needs to be agreed upon first.

llvm-svn: 240390

The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137

NFC.

llvm-svn: 232976

Patch by Kim Grasman!

llvm-svn: 224159

As a bonus we can actually check the return value.

llvm-svn: 224046

This interface was added 2 years ago but users never developed.

llvm-svn: 223368

mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files built for different architectures. Currently, 
MemoryBuffer has no easy way to map a subrange (slice) of a file which lld
will need to select a mach-o slice of a fat file. The new function provides 
an easy way to map a slice of a file into a MemoryBuffer. Test case included.

llvm-svn: 219260

getOpenFileSlice gets passed the map size, so it makes no sense to say that
the size is volatile. The code will not even compute the size.

llvm-svn: 219226

On this file we had a mix of
* Twine
* const char *
* StringRef

The two that make sense are
* const Twine & (caller convenience)
* consc char * (that is what will eventually be passed to open.

Given that sys::fs::openFileForRead takes a "const Twine &", I picked that.

llvm-svn: 219224

llvm-svn: 216583

The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

llvm-svn: 216488

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.

llvm-svn: 216002

llvm-svn: 215266

llvm-svn: 215248

the caller don't have to initialize it.

llvm-svn: 214994

On Cygwin, getpagesize() returns 64k(AllocationGranularity).

In r214580, the size of X86GenInstrInfo.inc became 1499136.

FIXME: We should reorganize again getPageSize() on Win32.
MapFile allocates address along AllocationGranularity but view is mapped by physical page.

llvm-svn: 214681

llvm-svn: 212405

While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.

This patch adds a simple llvm enumeration, which will hopefully avoid build
breakages in other platforms and surprises as we get more uses of
std::error_code.

llvm-svn: 210920

llvm-svn: 210873

llvm-svn: 210871

This should make sure that most new uses use the std prefix.

llvm-svn: 210835

This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.

llvm-svn: 210803

llvm-svn: 210772

llvm-svn: 210737

The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.

The cases where the general idea needed some tweaking:

* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.

* Template specialization had to be moved to the std namespace in this
patch set already.

* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.

Despite these shortcomings I think this is still a good thing. Some reasons:

* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.

llvm-svn: 210687

llvm-svn: 210630

There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.

llvm-svn: 209952

Removes old 4096 byte workaround. This functionality has been available since
Windows XP.

llvm-svn: 209137

Remove last uses of OwningPtr from llvm. As far as I can tell these method versions are not used by lldb, lld, or clang.

llvm-svn: 209103

Fix error handling introduced in r127426 that could result in MemoryBuffers not
having null termination.

llvm-svn: 208396

These were made redundant back in r186560.

llvm-svn: 208395

This can happen in practice with the user changing files and we can recover from it.

llvm-svn: 208143

[Support/MemoryBuffer] Rename IsVolatile -> IsVolatileSize and add a comment about the use case for the new parameter.

llvm-svn: 208026

[Support/MemoryBuffer] Move the IsVolatile check inside shouldUseMmap() and make sure to zero-initialize the rest
of the buffer if we unexpectedly reach end-of-file while reading.

llvm-svn: 208021

[Support/MemoryBuffer] Introduce a boolean parameter (false by default) 'IsVolatile' for the open file functions.

This provides a hint that the file may be changing often so mmap is avoided.

llvm-svn: 208007

llvm-svn: 205697

llvm-svn: 203442

This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.

llvm-svn: 202959

llvm-svn: 202621