<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Support/BinaryStreamWriter.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[Support] Use list-initialization for returning pairs (#160645)</title>
<updated>2025-09-25T15:51:55+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-09-25T15:51:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=78238dc9f8888a6c5ec42ceea24ae2bde801fb18'/>
<id>78238dc9f8888a6c5ec42ceea24ae2bde801fb18</id>
<content type='text'>
In C++17 and later, "return {A, B};" guarantees copy elision for a
std::pair return type, ensuring the object is constructed directly in
the return slot.  This patch updates those instances under Support/.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In C++17 and later, "return {A, B};" guarantees copy elision for a
std::pair return type, ensuring the object is constructed directly in
the return slot.  This patch updates those instances under Support/.</pre>
</div>
</content>
</entry>
<entry>
<title>Use llvm::endianness{,::little,::native} (NFC)</title>
<updated>2023-10-09T07:54:47+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-10-09T07:54:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d7b18d5083648c26b94adc2651edb87848138728'/>
<id>d7b18d5083648c26b94adc2651edb87848138728</id>
<content type='text'>
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form.  This patch replaces
llvm::support::endianness with llvm::endianness.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form.  This patch replaces
llvm::support::endianness with llvm::endianness.
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Add missing StringExtras.h includes</title>
<updated>2023-06-25T14:42:22+00:00</updated>
<author>
<name>Elliot Goodrich</name>
<email>elliotgoodrich@gmail.com</email>
</author>
<published>2023-06-17T12:18:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b0abd4893fa1bfae7f71b6b6e98770c9b1c07620'/>
<id>b0abd4893fa1bfae7f71b6b6e98770c9b1c07620</id>
<content type='text'>
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
</pre>
</div>
</content>
</entry>
<entry>
<title>[iwyu] Handle regressions in libLLVM header include</title>
<updated>2022-05-26T06:12:34+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@redhat.com</email>
</author>
<published>2022-05-25T20:29:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fb67d683db46dfd88da09d99bd5a318b7cc81513'/>
<id>fb67d683db46dfd88da09d99bd5a318b7cc81513</id>
<content type='text'>
Running iwyu-diff on LLVM codebase since 7030654296a0416bd9402a0278 detected a few
regressions, fixing them.

Differential Revision: https://reviews.llvm.org/D126417
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Running iwyu-diff on LLVM codebase since 7030654296a0416bd9402a0278 detected a few
regressions, fixing them.

Differential Revision: https://reviews.llvm.org/D126417
</pre>
</div>
</content>
</entry>
<entry>
<title>Make BinaryStreamWriter::padToAlignment write blocks vs bytes.</title>
<updated>2022-05-08T00:37:18+00:00</updated>
<author>
<name>Stella Laurenzo</name>
<email>stellaraccident@gmail.com</email>
</author>
<published>2022-05-02T02:20:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6dedbcd5e96ff36ea7d38534068a2d3e4746a929'/>
<id>6dedbcd5e96ff36ea7d38534068a2d3e4746a929</id>
<content type='text'>
While I think this is a performance improvement over the original, this actually fixes a correctness issue: For an appendable underlying stream, padToAlignment would fail if the additional padding would have caused the stream to grow since it was doing its own check on bounds. By deferring to the regular writeArray method this takes the same path as everything else, which does the correct bounds check in WritableBinaryStreamRef::checkOffsetForWrite (i.e. skips the extension check if BSF_Append is set). I had started to fix the existing bounds check in BinaryStreamWriter but deferred to this because it layered better and is more efficient/consistent.

It didn't look like this method was tested at all, so I added a unit test.

Differential Revision: https://reviews.llvm.org/D124746
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While I think this is a performance improvement over the original, this actually fixes a correctness issue: For an appendable underlying stream, padToAlignment would fail if the additional padding would have caused the stream to grow since it was doing its own check on bounds. By deferring to the regular writeArray method this takes the same path as everything else, which does the correct bounds check in WritableBinaryStreamRef::checkOffsetForWrite (i.e. skips the extension check if BSF_Append is set). I had started to fix the existing bounds check in BinaryStreamWriter but deferred to this because it layered better and is more efficient/consistent.

It didn't look like this method was tested at all, so I added a unit test.

Differential Revision: https://reviews.llvm.org/D124746
</pre>
</div>
</content>
</entry>
<entry>
<title>[Support] Convert BinaryStream class zoo to 64-bit offsets</title>
<updated>2021-09-16T23:14:52+00:00</updated>
<author>
<name>Nico Weber</name>
<email>thakis@chromium.org</email>
</author>
<published>2021-09-16T23:14:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=646299d183ca72cbafd3a2d64629ce8cb3fcdd9d'/>
<id>646299d183ca72cbafd3a2d64629ce8cb3fcdd9d</id>
<content type='text'>
Most PDB fields on disk are 32-bit but describe the file in terms of MSF
blocks, which are 4 kiB by default.

So PDB files can be a bit larger than 4 GiB, and much larger if you create them
with a block size &gt; 4 kiB.

This is a first (necessary, but by far not not sufficient) step towards
supporting such PDB files.  Now we don't truncate in-memory file offsets (which
are in terms of bytes, not in terms of blocks).

No effective behavior change. lld-link will still error out if it were to
produce PDBs &gt; 4 GiB.

Differential Revision: https://reviews.llvm.org/D109923
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most PDB fields on disk are 32-bit but describe the file in terms of MSF
blocks, which are 4 kiB by default.

So PDB files can be a bit larger than 4 GiB, and much larger if you create them
with a block size &gt; 4 kiB.

This is a first (necessary, but by far not not sufficient) step towards
supporting such PDB files.  Now we don't truncate in-memory file offsets (which
are in terms of bytes, not in terms of blocks).

No effective behavior change. lld-link will still error out if it were to
produce PDBs &gt; 4 GiB.

Differential Revision: https://reviews.llvm.org/D109923
</pre>
</div>
</content>
</entry>
<entry>
<title>[Support] Add LEB128 support to BinaryStreamReader/Writer.</title>
<updated>2019-04-17T15:38:27+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2019-04-17T15:38:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c1106c9b1161a120ccc0c44b0dcab0b403860ad2'/>
<id>c1106c9b1161a120ccc0c44b0dcab0b403860ad2</id>
<content type='text'>
Summary:
This patch adds support for ULEB128 and SLEB128 encoding and decoding to
BinaryStreamWriter and BinaryStreamReader respectively.

Support for ULEB128/SLEB128 will be used for eh-frame parsing in the JITLink
library currently under development (see https://reviews.llvm.org/D58704).

Reviewers: zturner, dblaikie

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 358584
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
This patch adds support for ULEB128 and SLEB128 encoding and decoding to
BinaryStreamWriter and BinaryStreamReader respectively.

Support for ULEB128/SLEB128 will be used for eh-frame parsing in the JITLink
library currently under development (see https://reviews.llvm.org/D58704).

Reviewers: zturner, dblaikie

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 358584
</pre>
</div>
</content>
</entry>
<entry>
<title>Update the file headers across all of the LLVM projects in the monorepo</title>
<updated>2019-01-19T08:50:56+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2019-01-19T08:50:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2946cd701067404b99c39fb29dc9c74bd7193eb3'/>
<id>2946cd701067404b99c39fb29dc9c74bd7193eb3</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[BinaryStream] Support growable streams.</title>
<updated>2017-11-27T18:48:37+00:00</updated>
<author>
<name>Zachary Turner</name>
<email>zturner@google.com</email>
</author>
<published>2017-11-27T18:48:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=96c6985b5327845be772c2bc13567c2967969cc7'/>
<id>96c6985b5327845be772c2bc13567c2967969cc7</id>
<content type='text'>
The existing library assumed that a stream's length would never
change.  This makes some things simpler, but it's not flexible
enough for what we need, especially for writable streams where
what you really want is for each call to write to actually append.

llvm-svn: 319070
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The existing library assumed that a stream's length would never
change.  This makes some things simpler, but it's not flexible
enough for what we need, especially for writable streams where
what you really want is for each call to write to actually append.

llvm-svn: 319070
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix buildbots.</title>
<updated>2017-06-16T02:42:33+00:00</updated>
<author>
<name>Rui Ueyama</name>
<email>ruiu@google.com</email>
</author>
<published>2017-06-16T02:42:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=af0f33a8532e2f28d39e92a43a59e694f20c0137'/>
<id>af0f33a8532e2f28d39e92a43a59e694f20c0137</id>
<content type='text'>
llvm-svn: 305542
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
llvm-svn: 305542
</pre>
</div>
</content>
</entry>
</feed>
