labath wrote: > The problem I encountered is that Dereference has 2 separate checks: the > first one checks if the type is a pointer or a reference, the second is done > if the first one succeeds and checks if a child with a type is actually found > by GetChildCompilerTypeAtIndex
Why does it need to do that? Is it so to control which error message gets printed? If so, I think we could tweak that text so that we don't need that. The string "not a pointer or reference type" is not correct anymore anyway since we don't know what is the criteria that a type system will use to determine if something is dereferencable. Maybe the type system should return an llvm::Error/Expected, and then caller figures out how (and whether) to print that? Also, could we reduce the number of arguments to that function? I'd hope that we don't need all of them since this is a very specific operation. E.g, I think the caller should be able to assume that the returned object is a "dereference" (whatever that means) of the parent instead of passing that via `child_is_deref_of_parent`. > I think the change in logic is allowing an array type pass the type check and > calling GetChildCompilerTypeAtIndex instead of checking for $$dereference$$ > synthetic value for the array type. I see. I'm still not worried about that because it means the array gets the same treatment as pointers. I think it's reasonable (though probably not very useful) that if a user registers a data formatter for `Foo*`, they should be able to provide a custom dereference operation that's different than "dereferencing the pointer". It doesn't work now, but if we ever wanted to make that possible, I don't think we'd need to (or should) treat pointers and arrays differently. 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
