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

Reply via email to