labath wrote: > > 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? > > From what I could understand, if we try to find a `$$dereference$$` when > `GetDereferencedType` fails for any reason, it ends up calling > `ValueObject::Dereference` again and goes into infinite recursion. It needs > to attempt dereferencing on valid types and not try to find `$$dereference$$` > when dereferencing fails. I'm not sure exactly what the cases are, but some > tests fail this way with this logic, for example `TestStlIncompleteTypes`. > Synthetic values just have to be checked only on invalid types.
Thank you for looking into this. I can see how something like this might happen, but that's not the conclusion I would draw from this, at least not without more data. I think we need to know how exactly is that recursion happening (e.g., the call stack). Since there is python code involved, it could be there's a bug there. The data formatters we write for tests aren't exactly battle-tested, and it's certainly possible to cause an infinite recursion with a bad data formatter. It's also possible that the implementation of `Dereference` is just too persistent. I think it's doing too much. I've created https://github.com/llvm/llvm-project/pull/137311 which I think is a better way to approach dereferencing (BTW, I think you'll need to do something similar in the new frame var implementation). You could try whether patching that in causes the recursion to go away. (Also, to avoid any confusion, I want to add that I don't consider this to be a requirement for merging #134428. I'm just waiting on that PR as you haven't responded to all of my comments.) 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
