<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Demangle/DLangDemangle.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>[Demangle] refactor DLangDemangle to use std::string_view</title>
<updated>2023-06-05T21:38:07+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2023-06-05T21:31:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=86b6ac5d54d7fe5cd21beff64b5c2194b1368bdf'/>
<id>86b6ac5d54d7fe5cd21beff64b5c2194b1368bdf</id>
<content type='text'>
Many existing methods of the D Language Demangler take a C style string
and return an adjusted pointer to the same object as the input string is
consumed.

Make it more obvious by changing the signatures to accept
std::string_view&amp; when the input is modified vs a copy of a
std::string_view when the input is not.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D152177
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many existing methods of the D Language Demangler take a C style string
and return an adjusted pointer to the same object as the input string is
consumed.

Make it more obvious by changing the signatures to accept
std::string_view&amp; when the input is modified vs a copy of a
std::string_view when the input is not.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D152177
</pre>
</div>
</content>
</entry>
<entry>
<title>[Damangle] convert dlangDemangle to use std::string_view</title>
<updated>2023-06-02T22:19:41+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2023-06-02T22:16:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f5371eb3d3aed06ba84a69533586a60243ad2f24'/>
<id>f5371eb3d3aed06ba84a69533586a60243ad2f24</id>
<content type='text'>
I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the D language
demangler, so convert it.

I have a more aggressive refactoring of the entire D language demangler
to use std::string_view more extensively, but the interface with
llvm::nonMicrosoftDemangle is the more interesting one.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D151003
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the D language
demangler, so convert it.

I have a more aggressive refactoring of the entire D language demangler
to use std::string_view more extensively, but the interface with
llvm::nonMicrosoftDemangle is the more interesting one.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D151003
</pre>
</div>
</content>
</entry>
<entry>
<title>Reland: [Demangle] replace use of llvm::StringView w/ std::string_view</title>
<updated>2023-04-20T18:22:20+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2023-04-20T18:08:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7c59e8001a3b66be545a890a26ad8a24a6c9fe4b'/>
<id>7c59e8001a3b66be545a890a26ad8a24a6c9fe4b</id>
<content type='text'>
This reverts commit d81cdb49d74064e88843733e7da92db865943509.

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Additional fixes for missing std::string_view conversions for MSVC.

Reviewed By: MaskRay, DavidSpickett, ayzhao

Differential Revision: https://reviews.llvm.org/D148546
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit d81cdb49d74064e88843733e7da92db865943509.

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Additional fixes for missing std::string_view conversions for MSVC.

Reviewed By: MaskRay, DavidSpickett, ayzhao

Differential Revision: https://reviews.llvm.org/D148546
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert D148384 "[Demangle] replace use of llvm::StringView w/ std::string_view"</title>
<updated>2023-04-15T01:42:11+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2023-04-15T01:42:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d81cdb49d74064e88843733e7da92db865943509'/>
<id>d81cdb49d74064e88843733e7da92db865943509</id>
<content type='text'>
This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still breaks Windows builds.

In addition, `#include &lt;llvm/ADT/StringViewExtras.h&gt;` in
llvm/include/llvm/Demangle/ItaniumDemangle.h is a library layering violation
(LLVMDemangle is the lowest LLVM library and cannot depend on LLVMSupport).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still breaks Windows builds.

In addition, `#include &lt;llvm/ADT/StringViewExtras.h&gt;` in
llvm/include/llvm/Demangle/ItaniumDemangle.h is a library layering violation
(LLVMDemangle is the lowest LLVM library and cannot depend on LLVMSupport).
</pre>
</div>
</content>
</entry>
<entry>
<title>[Demangle] replace use of llvm::StringView w/ std::string_view</title>
<updated>2023-04-14T22:48:38+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2023-04-14T22:43:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3e559509b426b6aae735a7f57dbdaed1041d2622'/>
<id>3e559509b426b6aae735a7f57dbdaed1041d2622</id>
<content type='text'>
This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D148384
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D148384
</pre>
</div>
</content>
</entry>
<entry>
<title>[demangler] Simplify OutputBuffer initialization</title>
<updated>2022-10-17T11:23:16+00:00</updated>
<author>
<name>Nathan Sidwell</name>
<email>nathan@acm.org</email>
</author>
<published>2022-02-28T18:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d3b10150b683142a7481893ddffe9206e1d29f95'/>
<id>d3b10150b683142a7481893ddffe9206e1d29f95</id>
<content type='text'>
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor.  Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.

a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes.  We need to avoid the UB of passing nullptr to
memcpy.

b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.

The original buffer initialization code would return a failure code if
that first malloc failed.  Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D122604
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor.  Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.

a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes.  We need to avoid the UB of passing nullptr to
memcpy.

b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.

The original buffer initialization code would return a failure code if
that first malloc failed.  Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D122604
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[demangler] Simplify OutputBuffer initialization"</title>
<updated>2022-04-26T20:24:06+00:00</updated>
<author>
<name>Kirill Stoimenov</name>
<email>kstoimenov@google.com</email>
</author>
<published>2022-04-26T20:24:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aabeb5eb7f0aaa2c80147d904959c882cdeba1e5'/>
<id>aabeb5eb7f0aaa2c80147d904959c882cdeba1e5</id>
<content type='text'>
Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c69b17f989e.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c69b17f989e.
</pre>
</div>
</content>
</entry>
<entry>
<title>[demangler] Simplify OutputBuffer initialization</title>
<updated>2022-04-26T11:23:12+00:00</updated>
<author>
<name>Nathan Sidwell</name>
<email>nathan@acm.org</email>
</author>
<published>2022-02-28T18:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5b3ca24a35e91bf9c19af856e7f92c69b17f989e'/>
<id>5b3ca24a35e91bf9c19af856e7f92c69b17f989e</id>
<content type='text'>
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor.  Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

The original buffer initialization code would return a failure code if
that first malloc failed.  Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D122604
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor.  Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

The original buffer initialization code would return a failure code if
that first malloc failed.  Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D122604
</pre>
</div>
</content>
</entry>
<entry>
<title>[Demangle] Pass Ret parameter from decodeNumber by reference</title>
<updated>2022-01-12T21:57:31+00:00</updated>
<author>
<name>Luís Ferreira</name>
<email>contact@lsferreira.net</email>
</author>
<published>2022-01-12T21:37:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6983968e833b03e8a25eba4d2a02e4d1b5d446a2'/>
<id>6983968e833b03e8a25eba4d2a02e4d1b5d446a2</id>
<content type='text'>
Since Ret parameter is never meant to be nullptr, let's pass it by reference instead of a raw pointer.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D117046
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since Ret parameter is never meant to be nullptr, let's pass it by reference instead of a raw pointer.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D117046
</pre>
</div>
</content>
</entry>
<entry>
<title>[Demangle] Add support for D types back referencing</title>
<updated>2022-01-12T21:57:31+00:00</updated>
<author>
<name>Luís Ferreira</name>
<email>contact@lsferreira.net</email>
</author>
<published>2022-01-12T21:37:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b21ea1c2701d754072b679c27df75c43699a2623'/>
<id>b21ea1c2701d754072b679c27df75c43699a2623</id>
<content type='text'>
    This patch adds support for type back referencing, allowing demangling of
    compressed mangled symbols with repetitive types.

    Signed-off-by: Luís Ferreira &lt;contact@lsferreira.net&gt;

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D111419
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
    This patch adds support for type back referencing, allowing demangling of
    compressed mangled symbols with repetitive types.

    Signed-off-by: Luís Ferreira &lt;contact@lsferreira.net&gt;

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D111419
</pre>
</div>
</content>
</entry>
</feed>
