History log of /llvm-project/llvm/lib/Demangle/DLangDemangle.cpp (Results 1 – 20 of 20)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6
# 86b6ac5d 05-Jun-2023 Nick Desaulniers <ndesaulniers@google.com>

[Demangle] refactor DLangDemangle to use std::string_view

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 strin

[Demangle] refactor DLangDemangle to use std::string_view

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& 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

show more ...


# f5371eb3 02-Jun-2023 Nick Desaulniers <ndesaulniers@google.com>

[Damangle] convert dlangDemangle to use std::string_view

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

[Damangle] convert dlangDemangle to use std::string_view

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

show more ...


Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3
# 7c59e800 20-Apr-2023 Nick Desaulniers <ndesaulniers@google.com>

Reland: [Demangle] replace use of llvm::StringView w/ std::string_view

This reverts commit d81cdb49d74064e88843733e7da92db865943509.

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

Leave

Reland: [Demangle] replace use of llvm::StringView w/ std::string_view

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

show more ...


Revision tags: llvmorg-16.0.2
# d81cdb49 15-Apr-2023 Fangrui Song <i@maskray.me>

Revert D148384 "[Demangle] replace use of llvm::StringView w/ std::string_view"

This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still

Revert D148384 "[Demangle] replace use of llvm::StringView w/ std::string_view"

This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still breaks Windows builds.

In addition, `#include <llvm/ADT/StringViewExtras.h>` in
llvm/include/llvm/Demangle/ItaniumDemangle.h is a library layering violation
(LLVMDemangle is the lowest LLVM library and cannot depend on LLVMSupport).

show more ...


# 3e559509 14-Apr-2023 Nick Desaulniers <ndesaulniers@google.com>

[Demangle] replace use of llvm::StringView w/ std::string_view

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

Leave StringView.h and cleanup around for subsequent cleanup.

Reviewed By:

[Demangle] replace use of llvm::StringView w/ std::string_view

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

show more ...


Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# d3b10150 28-Feb-2022 Nathan Sidwell <nathan@acm.org>

[demangler] Simplify OutputBuffer initialization

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

[demangler] Simplify OutputBuffer initialization

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

show more ...


# aabeb5eb 26-Apr-2022 Kirill Stoimenov <kstoimenov@google.com>

Revert "[demangler] Simplify OutputBuffer initialization"

Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c6

Revert "[demangler] Simplify OutputBuffer initialization"

Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c69b17f989e.

show more ...


# 5b3ca24a 28-Feb-2022 Nathan Sidwell <nathan@acm.org>

[demangler] Simplify OutputBuffer initialization

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

[demangler] Simplify OutputBuffer initialization

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

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# 6983968e 12-Jan-2022 Luís Ferreira <contact@lsferreira.net>

[Demangle] Pass Ret parameter from decodeNumber by reference

Since Ret parameter is never meant to be nullptr, let's pass it by reference instead of a raw pointer.

Reviewed By: dblaikie

Differenti

[Demangle] Pass Ret parameter from decodeNumber by reference

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

show more ...


# b21ea1c2 12-Jan-2022 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add support for D types back referencing

This patch adds support for type back referencing, allowing demangling of
compressed mangled symbols with repetitive types.

Signed-of

[Demangle] Add support for D types back referencing

This patch adds support for type back referencing, allowing demangling of
compressed mangled symbols with repetitive types.

Signed-off-by: Luís Ferreira <contact@lsferreira.net>

Reviewed By: dblaikie

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

show more ...


# bec08795 12-Jan-2022 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add support for D symbols back referencing

This patch adds support for identifier back referencing allowing compressed
mangled names by avoiding repetitiveness.

Signed-off-by

[Demangle] Add support for D symbols back referencing

This patch adds support for identifier back referencing allowing compressed
mangled names by avoiding repetitiveness.

Signed-off-by: Luís Ferreira <contact@lsferreira.net>

Reviewed By: dblaikie

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

show more ...


# 669bfcf0 12-Jan-2022 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add minimal support for D simple basic types

This patch implements simple demangling of two basic types to add minimal type functionality. This will be later used in function type parsing

[Demangle] Add minimal support for D simple basic types

This patch implements simple demangling of two basic types to add minimal type functionality. This will be later used in function type parsing. After that being implemented we can add the rest of the types and test the result of the type name.

Reviewed By: dblaikie

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

show more ...


Revision tags: llvmorg-13.0.1-rc2
# 83087c09 07-Dec-2021 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add support for D function-local parent symbols

Internally `__Sddd` function-local parent symbols are used to solve ambiguities on symbols in
the same scope with the same mangled

[Demangle] Add support for D function-local parent symbols

Internally `__Sddd` function-local parent symbols are used to solve ambiguities on symbols in
the same scope with the same mangled name.

Reviewed By: dblaikie

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

show more ...


# 8a7ddf9e 07-Dec-2021 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add support for D special identifiers

Reviewed By: dblaikie

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


# bd4c6a47 30-Nov-2021 David Blaikie <dblaikie@gmail.com>

Add missing header


# b779f02a 29-Nov-2021 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add support for D anonymous symbols

Anonymous symbols are represented by 0 in the mangled symbol. We should skip
them in order to represent the demangled name correctly, otherwise

[Demangle] Add support for D anonymous symbols

Anonymous symbols are represented by 0 in the mangled symbol. We should skip
them in order to represent the demangled name correctly, otherwise demangled
names like `demangle..anon` can happen.

Reviewed By: dblaikie

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

show more ...


# 6e08abdc 29-Nov-2021 David Blaikie <dblaikie@gmail.com>

[Demangle] Add support for multiple identifiers in D qualified names

Reviewed By: dblaikie

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


# e63c799a 29-Nov-2021 David Blaikie <dblaikie@gmail.com>

[Demangle] Add support for D simple single qualified names

This patch adds support for simple single qualified names that includes
internal mangled names and normal symbol names.

Differenti

[Demangle] Add support for D simple single qualified names

This patch adds support for simple single qualified names that includes
internal mangled names and normal symbol names.

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

show more ...


Revision tags: llvmorg-13.0.1-rc1
# 1bed03b5 10-Nov-2021 David Blaikie <dblaikie@gmail.com>

Fix memory leak in D demangler


# 22a1aa5a 09-Nov-2021 Luís Ferreira <contact@lsferreira.net>

[Demangle] Add minimal support for D programming language

This patch adds minimal support for D programming language demangling on LLVM
core based on the D name mangling spec. This will allow easier

[Demangle] Add minimal support for D programming language

This patch adds minimal support for D programming language demangling on LLVM
core based on the D name mangling spec. This will allow easier integration on a
future LLDB plugin for D either in the upstream tree or outside of it.

Minimal support includes recognizing D demangling encoding and at least one
mangling name, which in this case is `_Dmain` mangle.

Reviewed By: jhenderson, lattner

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

show more ...