aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/API/SBValue.cpp
AgeCommit message (Collapse)AuthorFilesLines
9 days[lldb] Use std::make_shared where possible (NFC) (#150714)Jonas Devlieghere1-5/+5
This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction).
2025-06-02[lldb] Refactor away UB in SBValue::GetLoadAddress (#141799)Pavel Labath1-4/+2
The problem was in calling GetLoadAddress on a value in the error state, where `ValueObject::GetLoadAddress` could end up accessing the uninitialized "address type" by-ref return value from `GetAddressOf`. This probably happened because each function expected the other to initialize it. We can guarantee initialization by turning this into a proper return value. I've added a test, but it only (reliably) crashes if lldb is built with ubsan.
2025-05-20[lldb] Retcon SBValue::GetChildAtIndex(synthetic=true) (#140065)Pavel Labath1-10/+9
The motivation here is being (un)able to treat pointer values as an array consistently. This works for pointers to simple/scalar values, but for aggregates, we get a very surprising result: - GetChildAtIndex(x, ??, true) returns the `x` child of the zeroth array member (the one you get by dereferencing the pointer/array) for all `x` which are smaller than the number of children of that value. - for other values of `x`, we get `v[x]`, where `v` is treated like a (C) pointer This patch reimagines this interface so that the value of `true` always treats (pointer and array) values as pointers. For `false`, we always dereference pointers, while in the case of arrays, we only return the values as far as the array bounds will allow. This has the potential to break existing code, but I have a suspicion that code was already broken to begin with, which is why I think this would be better than introducing a new API and keeping the old (and surprising) behavior. If our own test coverage is any indication, breakage should be minimal.
2025-04-30[lldb] Upgrade `GetIndexOfChildWithName` to use `llvm::Expected` (#136693)Charles Zablit1-3/+5
This patch replaces the use of `UINT32_MAX` as the error return value of `GetIndexOfChildWithName` with `llvm::Expected`. # Tasks to do in another PR 1. Replace `CalculateNumChildrenIgnoringErrors` with `CalculateNumChildren`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056319358). 2. Update `lldb_private::formatters::ExtractIndexFromString` to use `llvm::Expected`. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2054217536). 3. Create a new class which carries both user and internal errors. See [this comment](https://github.com/llvm/llvm-project/pull/136693#discussion_r2056439608).
2025-03-05[lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected (#129601)Adrian Prantl1-1/+1
This patch pushes the error handling boundary for the GetBitSize() methods from Runtime into the Type and CompilerType APIs. This makes it easier to diagnose problems thanks to more meaningful error messages being available. GetBitSize() is often the first thing LLDB asks about a type, so this method is particularly important for a better user experience. rdar://145667239
2024-11-21[lldb] Fix a regression in SBValue::GetObjectDescription() (#117242)Adrian Prantl1-2/+4
The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea. rdar://133956263
2024-10-24[lldb] Move ValueObject into its own library (NFC) (#113393)Jonas Devlieghere1-2/+2
ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: ``` find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; ```
2024-09-13Avoid expression evaluation in libStdC++ std::vector<bool> synthetic ↵jeffreytan811-0/+16
children provider (#108414) Our customers is reporting a serious performance issue (expanding a this pointer takes 70 seconds in VSCode) in a specific execution context. Profiling shows the hot path is triggered by an expression evaluation from libStdC++ synthetic children provider for `std::vector<bool>` since it uses `CreateValueFromExpression()`. This PR added a new `SBValue::CreateBoolValue()` API and switch `std::vector<bool>` synthetic children provider to use the new API without performing expression evaluation. Note: there might be other cases of `CreateValueFromExpression()` in our summary/synthetic children providers which I will sweep through in later PRs. With this PR, the customer's scenario reduces from 70 seconds => 50 seconds. I will add other PRs to further optimize the remaining 50 seconds (mostly from type/namespace lookup). Testing: `test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/vbool/TestDataFormatterStdVBool.py` passes with the PR --------- Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
2024-09-05[lldb] Make deep copies of Status explicit (NFC) (#107170)Adrian Prantl1-2/+2
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl1-21/+22
This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ` ResultTy DoFoo(Status& error) ` to ` llvm::Expected<ResultTy> DoFoo() ` How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly ` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) ` plus the occasional manual cleanup.
2024-07-15[API] add GetSyntheticValue (#95959)Vincent Belliard1-0/+15
Adds GetSyntheticValue to the API on top of GetNonSyntheticValue. --------- Co-authored-by: Vincent Belliard <v-bulle@github.com>
2024-06-20Refactor GetObjectDescription() to return llvm::Expected (NFC)Adrian Prantl1-1/+4
This is de facto an NFC change for Objective-C but will benefit the Swift language plugin.
2024-06-20Convert ValueObject::Dump() to return llvm::Error() (NFCish)Adrian Prantl1-1/+4
This change by itself has no measurable effect on the LLDB testsuite. I'm making it in preparation for threading through more errors in the Swift language plugin.
2024-06-13[LLDB] Add more helper functions to ValueObject class. (#87197)cmtice1-20/+2
Create additional helper functions for the ValueObject class, for: - returning the value as an APSInt or APFloat - additional type casting options - additional ways to create ValueObjects from various types of data - dereferencing a ValueObject These helper functions are needed for implementing the Data Inspection Language, described in https://discourse.llvm.org/t/rfc-data-inspection-language/69893
2024-04-25[lldb] Add SBValue::GetValueAsAddress API (#90144)Jason Molenda1-0/+19
I previously added this API via https://reviews.llvm.org/D142792 in 2023, along with changes to the ValueObject class to treat pointer types as addresses, and to annotate those ValueObjects with the original uint64_t byte sequence AND the name of the symbol once stripped, if that points to a symbol. I did this unconditionally for all pointer type ValueObjects, and it caused several regressions in the Objective-C data formatters which have a ValueObject of an object, it has the address of its class -- but with ObjC, sometimes it is a "tagged pointer" which is metadata, not an actual pointer. (e.g. a small NSInteger value is stored entirely in the tagged pointer, instead of a separate object) Treating these not-addresses as addresses -- clearing the non-addressable-bits -- is invalid. The original version of this patch we're using downstream only does this bits clearing for pointer types that are specifically decorated with the pointerauth typequal, but not all of those clang changes are upstreamed to github main yet, so I tried this simpler approach and hit the tagged pointer issue and bailed on the whole patch. This patch, however, is simply adding SBValue::GetValueAsAddress so script writers who know that an SBValue has an address in memory, can strip off any metadata. It's an important API to have for script writers when AArch64 ptrauth is in use, so I'm going to put this part of the patch back on github main now until we can get the rest of that original patch upstreamed.
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl1-1/+1
(#84219) Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected This is an NFC change that does not yet add any error handling or change any code to return any errors. This is the second big change in the patch series started with https://github.com/llvm/llvm-project/pull/83501 A follow-up PR will wire up error handling.
2024-03-08Revert "Change GetNumChildren()/CalculateNumChildren() methods return ↵Florian Mayer1-1/+1
llvm::Expected (#84219)" This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.
2024-03-08Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected ↵Adrian Prantl1-1/+1
(#84219) Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected This is an NFC change that does not yet add any error handling or change any code to return any errors. This is the second big change in the patch series started with https://github.com/llvm/llvm-project/pull/83501 A follow-up PR will wire up error handling.
2023-12-18[lldb] Fix a quirk in SBValue::GetDescription (#75793)Pavel Labath1-3/+8
The function was using the default version of ValueObject::Dump, which has a default of using the synthetic-ness of the top-level value for determining whether to print _all_ values as synthetic. This resulted in some unusual behavior, where e.g. a std::vector is stringified as synthetic if its dumped as the top level object, but in its raw form if it is a member of a struct without a pretty printer. The SBValue class already has properties which determine whether one should be looking at the synthetic view of the object (and also whether to use dynamic types), so it seems more natural to use that.
2023-10-30Add the ability to get a C++ vtable ValueObject from another ValueObj… ↵Greg Clayton1-3/+14
(#67599) Add the ability to get a C++ vtable ValueObject from another ValueObject. This patch adds the ability to ask a ValueObject for a ValueObject that represents the virtual function table for a C++ class. If the ValueObject is not a C++ class with a vtable, a valid ValueObject value will be returned that contains an appropriate error. If it is successful a valid ValueObject that represents vtable will be returned. The ValueObject that is returned will have a name that matches the demangled value for a C++ vtable mangled name like "vtable for <class-name>". It will have N children, one for each virtual function pointer. Each child's value is the function pointer itself, the summary is the symbolication of this function pointer, and the type will be a valid function pointer from the debug info if there is debug information corresponding to the virtual function pointer. The vtable SBValue will have the following: - SBValue::GetName() returns "vtable for <class>" - SBValue::GetValue() returns a string representation of the vtable address - SBValue::GetSummary() returns NULL - SBValue::GetType() returns a type appropriate for a uintptr_t type for the current process - SBValue::GetLoadAddress() returns the address of the vtable adderess - SBValue::GetValueAsUnsigned(...) returns the vtable address - SBValue::GetNumChildren() returns the number of virtual function pointers in the vtable - SBValue::GetChildAtIndex(...) returns a SBValue that represents a virtual function pointer The child SBValue objects that represent a virtual function pointer has the following values: - SBValue::GetName() returns "[%u]" where %u is the vtable function pointer index - SBValue::GetValue() returns a string representation of the virtual function pointer - SBValue::GetSummary() returns a symbolicated respresentation of the virtual function pointer - SBValue::GetType() returns the function prototype type if there is debug info, or a generic funtion prototype if there is no debug info - SBValue::GetLoadAddress() returns the address of the virtual function pointer - SBValue::GetValueAsUnsigned(...) returns the virtual function pointer - SBValue::GetNumChildren() returns 0 - SBValue::GetChildAtIndex(...) returns invalid SBValue for any index Examples of using this API via python: ``` (lldb) script vtable = lldb.frame.FindVariable("shape_ptr").GetVTable() (lldb) script vtable vtable for Shape = 0x0000000100004088 { [0] = 0x0000000100003d20 a.out`Shape::~Shape() at main.cpp:3 [1] = 0x0000000100003e4c a.out`Shape::~Shape() at main.cpp:3 [2] = 0x0000000100003e7c a.out`Shape::area() at main.cpp:4 [3] = 0x0000000100003e3c a.out`Shape::optional() at main.cpp:7 } (lldb) script c = vtable.GetChildAtIndex(0) (lldb) script c (void ()) [0] = 0x0000000100003d20 a.out`Shape::~Shape() at main.cpp:3 ```
2023-09-21Reland "[lldb] Add 'modify' type watchpoints, make it default (#66308)"David Spickett1-3/+10
This reverts commit a7b78cac9a77e3ef6bbbd8ab1a559891dc693401. With updates to the tests. TestWatchTaggedAddress.py: Updated the expected watchpoint types, though I'm not sure there should be a differnt default for the two ways of setting them, that needs to be confirmed. TestStepOverWatchpoint.py: Skipped this everywhere because I think what used to happen is you couldn't put 2 watchpoints on the same address (after alignment). I guess that this is now allowed because modify watchpoints aren't accounted for, but likely should be. Needs investigating.
2023-09-21Revert "[lldb] Add 'modify' type watchpoints, make it default (#66308)"David Spickett1-10/+3
This reverts commit 933ad5c897ee366759a54869b35b2d7285a92137. This caused 1 test failure and an unexpected pass on AArch64 Linux: https://lab.llvm.org/buildbot/#/builders/96/builds/45765 Wasn't reported because the bot was already red at the time.
2023-09-20[lldb] Add 'modify' type watchpoints, make it default (#66308)Jason Molenda1-3/+10
Watchpoints in lldb can be either 'read', 'write', or 'read/write'. This is exposing the actual behavior of hardware watchpoints. gdb has a different behavior: a "write" type watchpoint only stops when the watched memory region *changes*. A user is using a watchpoint for one of three reasons: 1. Want to find what is changing/corrupting this memory. 2. Want to find what is writing to this memory. 3. Want to find what is reading from this memory. I believe (1) is the most common use case for watchpoints, and it currently can't be done in lldb -- the user needs to continue every time the same value is written to the watched-memory manually. I think gdb's behavior is the correct one. There are some use cases where a developer wants to find every function that writes/reads to/from a memory region, regardless of value, I want to still allow that functionality. This is also a bit of groundwork for my large watchpoint support proposal https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 where I will be adding support for AArch64 MASK watchpoints which watch power-of-2 memory regions. A user might ask to watch 24 bytes, and a MASK watchpoint stub can do this with a 32-byte MASK watchpoint if it is properly aligned. And we need to ignore writes to the final 8 bytes of that watched region, and not show those hits to the user. This patch adds a new 'modify' watchpoint type and it is the default. Re-landing this patch after addressing testsuite failures found in CI on Linux, Intel machines, and windows. rdar://108234227
2023-09-18Revert "[lldb] Add 'modify' type watchpoints, make it default (#66308)"Jason Molenda1-10/+3
TestStepOverWatchpoint.py and TestUnalignedWatchpoint.py are failing on the ubuntu and debian bots https://lab.llvm.org/buildbot/#/builders/68/builds/60204 https://lab.llvm.org/buildbot/#/builders/96/builds/45623 and the newly added test TestModifyWatchpoint.py does not work on windows bot https://lab.llvm.org/buildbot/#/builders/219/builds/5708 I will debug tomorrow morning and reland. This reverts commit 3692267ca8f9c51cb55e4387283762d921fe2ae2.
2023-09-18[lldb] Add 'modify' type watchpoints, make it default (#66308)Jason Molenda1-3/+10
Watchpoints in lldb can be either 'read', 'write', or 'read/write'. This is exposing the actual behavior of hardware watchpoints. gdb has a different behavior: a "write" type watchpoint only stops when the watched memory region *changes*. A user is using a watchpoint for one of three reasons: 1. Want to find what is changing/corrupting this memory. 2. Want to find what is writing to this memory. 3. Want to find what is reading from this memory. I believe (1) is the most common use case for watchpoints, and it currently can't be done in lldb -- the user needs to continue every time the same value is written to the watched-memory manually. I think gdb's behavior is the correct one. There are some use cases where a developer wants to find every function that writes/reads to/from a memory region, regardless of value, I want to still allow that functionality. This is also a bit of groundwork for my large watchpoint support proposal https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 where I will be adding support for AArch64 MASK watchpoints which watch power-of-2 memory regions. A user might ask to watch 24 bytes, and a MASK watchpoint stub can do this with a 32-byte MASK watchpoint if it is properly aligned. And we need to ignore writes to the final 8 bytes of that watched region, and not show those hits to the user. This patch adds a new 'modify' watchpoint type and it is the default. rdar://108234227
2023-08-09[lldb] Sink StreamFile into lldbHostAlex Langford1-1/+0
StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libraries, so I think it makes sense for this to live in lldbHost instead. Differential Revision: https://reviews.llvm.org/D157460
2023-06-13[lldb] Default can_create to true in GetChildAtIndex (NFC)Dave Lee1-1/+1
Existing callers of `GetChildAtIndex` pass true for can_create. This change makes true the default value, callers don't have to pass an opaque true. See also D151966 for the same change to `GetChildMemberWithName`. Differential Revision: https://reviews.llvm.org/D152031
2023-06-13[lldb] Default can_create to true in GetChildMemberWithName (NFC)Dave Lee1-1/+1
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`. This change makes `true` the default value, callers don't have to pass an opaque true. Differential Revision: https://reviews.llvm.org/D151966
2023-06-01[lldb] Take StringRef name in GetIndexOfChildWithName (NFC)Dave Lee1-1/+1
As with D151615, which changed `GetIndexOfChildMemberWithName` to take a `StringRef` instead of a `ConstString`, this change does the same for `GetIndexOfChildWithName`. Differential Revision: https://reviews.llvm.org/D151811
2023-05-31[lldb] Take StringRef name in GetChildMemberWithName (NFC)Dave Lee1-2/+1
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function take a `StringRef` instead, which alleviates the need for callers to construct a `ConstString`. I don't expect this change to improve performance, only ergonomics. This is in support of Alex's effort to replace `ConstString` where appropriate. There are related `ValueObject` functions that can also be changed, if this is accepted. Differential Revision: https://reviews.llvm.org/D151615
2023-05-18[lldb] Guarantee the lifetimes of all strings returned from SBAPIAlex Langford1-37/+23
LLDB should guarantee that the strings returned by SBAPI methods live forever. I went through every method that returns a string and made sure that it was added to the ConstString StringPool before returning if it wasn't obvious that it was already doing so. I've also updated the docs to document this behavior. Differential Revision: https://reviews.llvm.org/D150804
2023-03-02Revert "Add SBValue::GetValueAsAddress API for removing non-addressing metadata"Jason Molenda1-20/+0
Revert while I investigate two CI bot failures; the more important is the lldb-arm-ubuntu where the FixAddress is removing the 0th bit so we're adding the `actual=` decorator on a string pointer, ``` Got output: (char *) strptr = 0x00400817 (actual=0x400816) ptr = [{ },{H}] ``` in TestDataFormatterSmartArray.py line 229. This reverts commit 4d635be2dbadc77522eddc9668697385a3b9f8b4.
2023-03-02Add SBValue::GetValueAsAddress API for removing non-addressing metadataJason Molenda1-0/+20
On target where metadata is stored in bits that aren't used for virtual addressing -- AArch64 Top Byte Ignore and pointer authentication are two examples -- an SBValue object representing a pointer will return the address with metadata for SBValue::GetValueAsUnsigned. Users may want to get the virtual address without the metadata; this new method gives them a way to do this. Differential Revision: https://reviews.llvm.org/D142792
2023-02-28An SBValue whose underlying ValueObject has no valid value, but doesJim Ingham1-1/+10
hold an error should: (a) return false for IsValid, since that's the current behavior and is a convenient way to check "should I get the value for this". (b) preserve the error when an SBValue is made from it, and print the error in the ValueObjectPrinter. Make that happen. Differential Revision: https://reviews.llvm.org/D144664
2022-06-19[lldb] Use value_or instead of getValueOr (NFC)Kazu Hirata1-1/+1
2022-03-31[LLDB] Applying clang-tidy modernize-use-equals-default over LLDBShafik Yaghmour1-3/+1
Applied modernize-use-equals-default clang-tidy check over LLDB. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121844
2022-01-20[lldb] Decouple instrumentation from the reproducersJonas Devlieghere1-133/+88
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros. Differential revision: https://reviews.llvm.org/D117712
2022-01-09[lldb] Remove LLDB_RECORD_RESULT macroJonas Devlieghere1-51/+49
2022-01-09[lldb] Remove reproducer instrumentationJonas Devlieghere1-128/+1
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details. [1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html Differential revision: https://reviews.llvm.org/D116847
2022-01-02[API] Remove redundant member initialization (NFC)Kazu Hirata1-3/+3
Identified with readability-redundant-member-init.
2021-11-22[formatters] Add a formatter for libstdc++ optionalWalter Erquinigo1-0/+13
Besides adding the formatter and the summary, this makes the libcxx tests also work for this case. This is the polished version of https://reviews.llvm.org/D114266, authored by Danil Stefaniuc. Differential Revision: https://reviews.llvm.org/D114403
2021-05-04[lldb] Move and clean-up the Declaration class (NFC)Med Ismail Bennani1-1/+1
This patch moves the Declaration class from the Symbol library to the Core library. This will allow to use it in a more generic fashion and aims to lower the dependency cycles when it comes to the linking. The patch also does some cleaning up by making column information permanent and removing the LLDB_ENABLE_DECLARATION_COLUMNS directives. Differential revision: https://reviews.llvm.org/D101556 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-09-29[lldb] Remove redundant ctor call (NFC)Jonas Devlieghere1-1/+1
As pointed out by Pavel in D88249.
2020-09-25[lldb] Pass reference instead of pointer in protected SBAddress methods.Jonas Devlieghere1-1/+1
Every call to the protected SBAddress constructor and the SetAddress method takes the address of a valid object which means we might as well pass it as a const reference instead of a pointer and drop the null check. Differential revision: https://reviews.llvm.org/D88249
2020-07-27Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)Adrian Prantl1-1/+1
This cleanup patch unifies all methods called GetByteSize() in the ValueObject hierarchy to return an optional, like the methods in CompilerType do. This means fewer magic 0 values, which could fix bugs down the road in languages where types can have a size of zero, such as Swift and C (but not C++). Differential Revision: https://reviews.llvm.org/D84285 This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
2020-07-25Temporarily Revert "Unify the return value of GetByteSize to an ↵Eric Christopher1-1/+1
llvm::Optional<uint64_t> (NFC-ish)" as it's causing numerous (176) test failures on linux. This reverts commit 1d9b860fb6a85df33fd52fcacc6a5efb421621bd.
2020-07-25Unify the return value of GetByteSize to an llvm::Optional<uint64_t> (NFC-ish)Adrian Prantl1-1/+1
This cleanup patch unifies all methods called GetByteSize() in the ValueObject hierarchy to return an optional, like the methods in CompilerType do. This means fewer magic 0 values, which could fix bugs down the road in languages where types can have a size of zero, such as Swift and C (but not C++). Differential Revision: https://reviews.llvm.org/D84285
2020-05-08[lldb] Remove 'use_synthetic' parameters in ValueObject codeRaphael Isemann1-1/+1
Summary: `CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter that makes the function do nothing when it's false. We obviously always pass true to the function (or check that the value we pass is true), because there really isn't any point calling with function with a `false`. This just removes all of this. Reviewers: labath, JDevlieghere, davide Reviewed By: davide Subscribers: davide Differential Revision: https://reviews.llvm.org/D79568
2020-02-17[lldb] Replace empty ctor en dtor bodies with =default (NFC)Jonas Devlieghere1-3/+3
Use = default instead of empty constructor and destructor bodies in the API layer.
2020-02-03[lldb] Remove unused parameter from ValueObject::GetExpressionPathAlex Langford1-2/+2
I previously removed the code in ValueObject::GetExpressionPath that took advantage of the parameter `qualify_cxx_base_classes`. As a result, this is now unused and can be removed.
generated by cgit v1.1 at 2025-08-03 13:42:35 +0000