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