cmtice wrote: > Even though you've removed the smart pointer checking function (the most > obvious example of language-specific behavior), I'm still worried about > whether the overall design of this code will allow you to avoid it. > I believe I have fixed all the code to avoid any need to to smart pointer checking -- I went back and looked very closely at what the current frame variable implementation does when handling smart pointers, and tried to do the same thing, which appears to have worked.
> Looking at the `IdentifierInfo` class, I see that it can be constructed with > only a type (the value is optional). I think this is going to be very hard to > make work, since a type does not know if its a smart pointer (only a value > does). Have you already figured out a way to make that work? > The case where it is constructed only with a type is meant to be when handling LLDB convenience variables (the dynamic variables names "$..."); I'm not sure if those can be smart pointers? > IndentifierInfo isn't the only suspicious place though. All of the places > that are doing something with bitfield offsets are very suspicious to me, as > that's something that the Values should already know. > > I haven't seen the parser, but I wouldn't be surprised if this has something > to do with the vexing parse issues of C languages, where one needs to know if > something is a type just to parse the expression correctly. Now, if that's > the case, and if really need to know if something is a smart pointer (i.e. > whether it is dereferencable) without having access to a value of that type, > then we may need to have a bigger discussion about what to do about that. I would be happy to share the parser code with you and walk/talk you through it, if that would help? https://github.com/llvm/llvm-project/pull/95738 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
