summaryrefslogtreecommitdiff
path: root/lldb/source/Core/RichManglingContext.cpp
AgeCommit message (Collapse)Author
2025-04-14[LLDB] Reapply refactored CPlusPlusLanguage::MethodName to break lldb-server ↵Dmitry Vasilyev
dependencies (#135033) The original PR is #132274. Co-authored-by: @bulbazord Alex Langford
2025-04-09Revert "[LLDB] Refactored CPlusPlusLanguage::MethodName to break lldb-server ↵David Spickett
dependencies" (#134995) Reverts llvm/llvm-project#132274 Broke a test on LLDB Widows on Arm: https://lab.llvm.org/buildbot/#/builders/141/builds/7726 ``` FAIL: test_dwarf (lldbsuite.test.lldbtest.TestExternCSymbols.test_dwarf) <...> self.assertTrue(self.res.Succeeded(), msg + output) AssertionError: False is not true : Command 'expression -- foo()' did not return successfully Error output: error: Couldn't look up symbols: int foo(void) Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler. ```
2025-04-09[LLDB] Refactored CPlusPlusLanguage::MethodName to break lldb-server ↵Dmitry Vasilyev
dependencies (#132274) This patch addresses the issue #129543. After this patch the size of lldb-server is reduced by 9MB. Co-authored-by: @bulbazord Alex Langford
2023-12-16[lldb] Use StringRef::{starts,ends}_with (NFC)Kazu Hirata
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.
2022-08-20[lldb] Use Any::has_value instead of ANy::hasValue (NFC)Kazu Hirata
2022-02-18[lldb] Add llvm_unreachable in RichManglingContextDave Lee
Add `llvm_unreachable` to prevent warnings/errors in gcc and msvc. Differential Revision: https://reviews.llvm.org/D119737
2022-02-04[lldb] Improve RichManglingContext ergonomics (NFC)Jonas Devlieghere
Have the different ::Parse.* methods return the demangled string directly instead of having to go through ::GetBufferRef. Differential revision: https://reviews.llvm.org/D118953
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath
2021-08-23[lldb][NFC] Remove unused method RichManglingContext::IsFunctionAlex Langford
2021-04-21[lldb] Fix RichManglingContext::FromCxxMethodName() leakJordan Rupprecht
`RichManglingContext::FromCxxMethodName` allocates a m_cxx_method_parser, but never deletes it. This fixes a `-DLLVM_USE_SANITIZER=Leaks` failure. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D100795
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
2019-03-06Pass ConstString by value (NFC)Adrian Prantl
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-08-31Silence some "control reaches end of non-void function" warnings with gccPavel Labath
llvm-svn: 341163
2018-08-10RichManglingContext: Make m_ipd_str_len a local variable and simplify ↵Stefan Granitz
processIPDStrResult + polishing in test and Mangled llvm-svn: 339440
2018-08-08Use rich mangling information in Symtab::InitNameIndexes()Stefan Granitz
Summary: I set up a new review, because not all the code I touched was marked as a change in old one anymore. In preparation for this review, there were two earlier ones: * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function Primary goals for this patch are: (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index. (2) Provide a uniform interface. (3) Improve indexing performance. The central implementation in this patch is our new function for explicit demangling: ``` const RichManglingInfo * Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *) ``` It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are: * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`). * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing. The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`. Future potential: * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.) * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages. One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess). First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think. Reviewers: labath, jingham, JDevlieghere, erik.pilkington Subscribers: zturner, clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50071 llvm-svn: 339291