================
@@ -2794,47 +2794,31 @@ ValueObjectSP ValueObject::Dereference(Status &error) {
if (m_deref_valobj)
return m_deref_valobj->GetSP();
- const bool is_pointer_or_reference_type = IsPointerOrReferenceType();
- if (is_pointer_or_reference_type) {
- bool omit_empty_base_classes = true;
- bool ignore_array_bounds = false;
-
- std::string child_name_str;
- uint32_t child_byte_size = 0;
- int32_t child_byte_offset = 0;
- uint32_t child_bitfield_bit_size = 0;
- uint32_t child_bitfield_bit_offset = 0;
- bool child_is_base_class = false;
- bool child_is_deref_of_parent = false;
- const bool transparent_pointers = false;
- CompilerType compiler_type = GetCompilerType();
- uint64_t language_flags = 0;
+ std::string child_name_str;
+ uint32_t child_byte_size = 0;
----------------
jimingham wrote:
This is a tiny nit, but I find this flow harder to read because I don't
understand why you use both "child" and "deref" as prefixes related to the
defererenced object. I had to think a bit to realize that this distinction was
without difference...
It is true that in strict lldb terms, the deference valobj is a child of the
valobj it is the dereference of, but that's the least interesting aspect of it
here.
For instance, it's odd that `child_name_str` is the name that you are going to
give to `m_deref_valobj`, or when you assign `deref_error` from
`child_type_or_err`.
https://github.com/llvm/llvm-project/pull/135843
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
