================ @@ -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