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.
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
The problem is that synthetic value objects can sometimes represent objects in target memory, and other times they might be made up wholly in lldb memory, with pointers from one synthetic object to another, and so the ValueObjectVariable computation was not appropriate.
This patch delegates the computation to the root of the ValueObject in question. That solves the problem for ValueObjectVariable while not messing up the computation for ValueObjectConstResult or ValueObjectSynthetic.
Differential Revision: https://reviews.llvm.org/D83450
The patch fixes a crash in ValueObject::CreateChildAtIndex caused by a
null pointer dereferencing. This is a corner case that is happening when
trying to dereference a variable with an incomplete type, and this same
variable doesn't have a synthetic value to get the child ValueObject.
If this happens, lldb will now return a null pointer that will results
in an error message.
rdar://65181171
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.
These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.
This means that: (unsigned long)(int)-1
is equal to (unsigned long)0xffffffffffffffff
and not (unsigned long)0x00000000ffffffff
Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.
This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82772
This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets introduced
previously but did require some adjustments in Core::ValueObject.
Since the "Ref" types are opaque pointers to the actual CF containers, if the
value object has a synthetic value, lldb will use the opaque pointer's pointee
type to create the new ValueObjectChild needed to dereference the ValueObject.
This allows the "Ref" types to behaves the same as CF containers when used with
the `frame variable` command, the SBAPI or in Xcode's variable inspector.
This patch also adds support for incomplete types in ValueObject.
rdar://53104287
Differential Revision: https://reviews.llvm.org/D79554
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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
We currently rely on the TypeSystem implementation to initialize this value
with 0 in the GetChildCompilerTypeAtIndex call below. Let's just initialize
this variable like the rest.
Summary:
Detection of C strings does not work well for pointers. If the value object holding a (char*) pointer does not have an address (e.g., if it is a temp), the value is not considered a C string and its formatting is left to DumpDataExtractor rather than the special handling in ValueObject::DumpPrintableRepresentation. This leads to inconsistent outputs, e.g., in escaping non-ASCII characters. See the test for an example; the second test expectation is not met (without this patch). With this patch, the C string detection only insists that the pointer value is valid. The patch makes the code consistent with how the pointer is obtained in ValueObject::ReadPointedString.
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76650
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not. It
got broken when the PersistentExpressionState was refactored.
This fixes the issue and provides a test of the behavior.
Differential Revision: https://reviews.llvm.org/D76532
Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.
This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.
Reviewers: teemperor, JDevlieghere, jingham
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74153
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
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.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Summary:
This method has exactly one call site, which is only actually executed
if `ValueObject::IsBaseClass` returns false. However, the first thing
that `ValueObject::GetBaseClassPath` does is check if `ValueObject::IsBaseClass`
is true. Because this can never be the case, this method always returns false
and is therefore effectively dead.
Differential Revision: https://reviews.llvm.org/D73517
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
Adrian Prantl
Raphael Isemann
Eric Christopher
Jim Ingham
Pavel Labath
Med Ismail Bennani
Jaroslav Sevcik
Pavel Labath
Alex Langford
Benjamin Kramer