[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial si

[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.

show more ...

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber Stri

[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[llvm] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[llvm] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[Support][MemBuffer] Prevent UB on empty StringRefs

Empty StringRefs are usually identified by their length being zero, and
sometimes they'll have Data==nullptr (e.g. default constructed, or derived

[Support][MemBuffer] Prevent UB on empty StringRefs

Empty StringRefs are usually identified by their length being zero, and
sometimes they'll have Data==nullptr (e.g. default constructed, or derived from
an operation like split/copy and result turned out to be empty).

If such StringRef objects are passed to llvm::MemoryBuffer::getMemBufferCopy,
it'll result in UB as neither src nor dst can be null, even if size is zero.

This patch prevents that UB by not issuing a copy whenever StringRef is empty.

Differential Revision: https://reviews.llvm.org/D144706

show more ...

[MemoryBuffer] Allow optionally specifying desired buffer alignment

Underlying data may have requirements/expectations/etc. about
the run-time alignment. WritableMemoryBuffer currently uses
a 16 byt

[MemoryBuffer] Allow optionally specifying desired buffer alignment

Underlying data may have requirements/expectations/etc. about
the run-time alignment. WritableMemoryBuffer currently uses
a 16 byte alignment, which works for many situations but not all.
Allowing a desired alignment makes it easier to reuse WritableMemoryBuffer
in situations of special alignment, and also removes a problem when
opening files with special alignment constraints. Large files generally
get mmaped, which has ~page alignment, but small files go through
WritableMemoryBuffer which has the much smaller alignment guarantee.

Differential Revision: https://reviews.llvm.org/D137820

show more ...

Fixed a roll-over on size_t in getNewUninitMemBuffer()

Reviewed By: serge-sans-paille

Differential Revision: https://reviews.llvm.org/D121399

[NFCI][Support] Avoid ASSERT_/EXPECT_TRUE(A <op> B)

The error messages in tests are far better when a test fails if the test
is written using ASSERT_/EXPECT_<operator>(A, B) rather than
ASSERT_/EXPE

[NFCI][Support] Avoid ASSERT_/EXPECT_TRUE(A <op> B)

The error messages in tests are far better when a test fails if the test
is written using ASSERT_/EXPECT_<operator>(A, B) rather than
ASSERT_/EXPECT_TRUE(A <operator> B).

This commit updates all of llvm/unittests/Support to use these macros
where possible.

This change has not been possible in:
- llvm/unittests/Support/FSUniqueIDTest.cpp - due to not overloading
operators beyond ==, != and <.
- llvm/unittests/Support/BranchProbabilityTest.cpp - where the unchanged
tests are of the operator overloads themselves.

There are other possibilities of this conversion not being valid, which
have not applied in these tests, as they do not use NULL (they use
nullptr), and they do not use const char* (they use std::string or
StringRef).

Reviewed By: mubashar_

Differential Revision: https://reviews.llvm.org/D117319

show more ...

[llvm] Add null-termination capability to SmallVectorMemoryBuffer

Most of `MemoryBuffer` interfaces expose a `RequiresNullTerminator` parameter that's being used to:
* determine how to open a file (

[llvm] Add null-termination capability to SmallVectorMemoryBuffer

Most of `MemoryBuffer` interfaces expose a `RequiresNullTerminator` parameter that's being used to:
* determine how to open a file (`mmap` vs `open`),
* assert newly initialized buffer indeed has an implicit null terminator.

This patch adds the paramater to the `SmallVectorMemoryBuffer` constructors, meaning:
* null terminator can now be added to `SmallVector`s that didn't have one before,
* `SmallVectors` that had a null terminator before keep it even after the move.

In line with existing code, the new parameter is defaulted to `true`. This patch makes sure all calls to the `SmallVectorMemoryBuffer` constructor set it to `false` to preserve the current semantics.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D115331

show more ...

Support: Add operator== for MemoryBufferRef and split out MemoryBufferRef.h

As preparation for changing `LineIterator` to work with `MemoryBufferRef`:

- Add an `operator==` that uses buffer pointer

Support: Add operator== for MemoryBufferRef and split out MemoryBufferRef.h

As preparation for changing `LineIterator` to work with `MemoryBufferRef`:

- Add an `operator==` that uses buffer pointer identity to ensure two buffers
are equivalent.
- Split out `MemoryBufferRef.h`, to avoid polluting `LineIterator.h` includers
with everything from `MemoryBuffer.h`. This also means moving the
`MemoryBuffer` constructor to a source file.

Differential Revision: https://reviews.llvm.org/D89279

show more ...

[LLVM][SupportTests] Ask the OS how large the page size is instead of guessing.

PPC64 had a larger than expected page size. Instead of guessing just
use the same API that `MemoryBuffer` does to dete

[LLVM][SupportTests] Ask the OS how large the page size is instead of guessing.

PPC64 had a larger than expected page size. Instead of guessing just
use the same API that `MemoryBuffer` does to determine the page size.

show more ...

[LLVM][SupportTests] Fix Windows build breakage

`MemoryBuffer::getOpenFile` take an OS file handle, not an int.

[Clang] Expose RequiresNullTerminator in FileManager.

This is needed to fix the reason
0a2be46cfdb698fe (Modules: Invalidate out-of-date PCMs as they're
discovered) and 5b44a4b07fc1d ([modules] Do n

[Clang] Expose RequiresNullTerminator in FileManager.

This is needed to fix the reason
0a2be46cfdb698fe (Modules: Invalidate out-of-date PCMs as they're
discovered) and 5b44a4b07fc1d ([modules] Do not cache invalid state for
modules that we attempted to load.) were reverted.

These patches changed Clang to use `isVolatile` when loading modules.
This had the side effect of not using mmap when loading modules, and
thus greatly increased memory usage.

The reason it wasn't using mmap is because `MemoryBuffer` plays some
games with file size when you request null termination, and it has to
disable these when `isVolatile` is set as the size may change by the
time it's mmapped. Clang by default passes
`RequiresNullTerminator = true`, and `shouldUseMmap` ignored if
`RequiresNullTerminator` was even requested.

This patch adds `RequiresNullTerminator` to the `FileManager` interface
so Clang can use it when loading modules, and changes `shouldUseMmap` to
only take volatility into account if `RequiresNullTerminator` is true.
This is fine as both `mmap` and a `read` loop are vulnerable to
modifying the file while reading, but are immune to the rename Clang
does when replacing a module file.

Differential Revision: https://reviews.llvm.org/D77772

show more ...

[Support] Improve readNativeFile(Slice) interface

Summary:
There was a subtle, but pretty important difference between the Slice
and regular versions of this function. The Slice function was
zero-in

[Support] Improve readNativeFile(Slice) interface

Summary:
There was a subtle, but pretty important difference between the Slice
and regular versions of this function. The Slice function was
zero-initializing the rest of the buffer when the read syscall returned
less bytes than expected, while the regular function did not.

This patch removes the inconsistency by making both functions *not*
zero-initialize the buffer. The zeroing code is moved to the
MemoryBuffer class, which is currently the only user of this code. This
makes the API more consistent, and the code shorter.

While in there, I also refactor the functions to return the number of
bytes through the regular return value (via Expected<size_t>) instead of
a separate by-ref argument.

Reviewers: aganea, rnk

Subscribers: kristina, Bigcheese, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66471

llvm-svn: 369627

show more ...

Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"

This recommits r368977, which was reverted in r369027 due to test
failures in lldb. The cause of this was different behavior of

Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"

This recommits r368977, which was reverted in r369027 due to test
failures in lldb. The cause of this was different behavior of
readNativeFileSlice on windows and unix. These have been addressed in
r369269.

The original commit message was:
In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling back to a
"pread()", but it was failing to check the result of that system call.
This meant that the function would return "success" even though the read
operation failed, and it returned a buffer full of uninitialized memory.

Reviewers: rnk, dblaikie

Subscribers: kristina, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66224

llvm-svn: 369370

show more ...

Revert "MemoryBuffer: Add a missing error-check to getOpenFileImpl"

This reverts commit r368977 because it broke a couple of tests in lldb.

llvm-svn: 369027

MemoryBuffer: Add a missing error-check to getOpenFileImpl

Summary:
In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling ba

MemoryBuffer: Add a missing error-check to getOpenFileImpl

Summary:
In case the function was called with a desired read size *and* the file
was not an "mmap()" candidate, the function was falling back to a
"pread()", but it was failing to check the result of that system call.
This meant that the function would return "success" even though the read
operation failed, and it returned a buffer full of uninitialized memory.

Reviewers: rnk, dblaikie

Subscribers: kristina, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66224

llvm-svn: 368977

show more ...

[Support] Move llvm::MemoryBuffer to sys::fs::file_t

Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard

[Support] Move llvm::MemoryBuffer to sys::fs::file_t

Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.

For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.

Reviewers: aganea, Bigcheese

Reviewed By: aganea

Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D63453

llvm-svn: 365588

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[Support] Pacify -Wsign-compare in unit test.

llvm-svn: 327070

[Support] Add WriteThroughMemoryBuffer.

This is like MemoryBuffer (read-only) and WritableMemoryBuffer
(writable private), but where the underlying file can be modified
after writing. This is usefu

[Support] Add WriteThroughMemoryBuffer.

This is like MemoryBuffer (read-only) and WritableMemoryBuffer
(writable private), but where the underlying file can be modified
after writing. This is useful when you want to open a file, make
some targeted edits, and then write it back out.

Differential Revision: https://reviews.llvm.org/D44230

llvm-svn: 327057

show more ...

[Support] Add WritableMemoryBuffer::getNewMemBuffer

Summary:
The idea is that it would replace
(non-Writable)MemoryBuffer::getNewMemBuffer, which is quite useless
unless you const_cast its contents

[Support] Add WritableMemoryBuffer::getNewMemBuffer

Summary:
The idea is that it would replace
(non-Writable)MemoryBuffer::getNewMemBuffer, which is quite useless
unless you const_cast its contents to write to it (which all (both)
callers of this function were doing). This patch also fixes one of the usages in
COFFWriter. After fixing the other usage in clang, I plan to delete the old
function.

Reviewers: dblaikie, Bigcheese

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D41540

llvm-svn: 322094

show more ...

[Support] Remove MemoryBuffer::getNewUninitMemBuffer

There is nothing useful that can be done with a read-only uninitialized
buffer without const_casting its contents to initialize it. A better
solu

[Support] Remove MemoryBuffer::getNewUninitMemBuffer

There is nothing useful that can be done with a read-only uninitialized
buffer without const_casting its contents to initialize it. A better
solution is to obtain a writable buffer
(WritableMemoryBuffer::getNewUninitMemBuffer), and then convert it to a
read-only buffer after initialization. All callers of this function have
already been updated to do this, so this function is now unused.

llvm-svn: 321257

show more ...

[Support] Add WritableMemoryBuffer class

Summary:
The motivation here is LLDB, where we need to fixup relocations in
mmapped files before their contents can be read correctly. The
MemoryBuffer clas

[Support] Add WritableMemoryBuffer class

Summary:
The motivation here is LLDB, where we need to fixup relocations in
mmapped files before their contents can be read correctly. The
MemoryBuffer class does exactly what we need, *except* that it maps the
file in read-only mode.

WritableMemoryBuffer reuses the existing machinery for opening and
mmapping a file. The only difference is in the argument to the
mapped_file_region constructor -- we create a private copy-on-write
mapping, so that we can make changes to the mapped data, but the changes
aren't carried over to the underlying file.

This patch is based on an initial version by Zachary Turner.

Reviewers: mehdi_amini, rnk, rafael, dblaikie, zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D40291

llvm-svn: 321071

show more ...

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consi

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786

show more ...

Try to fix some temp file leaks in SupportTests, PR18335

llvm-svn: 280443