mboehme added a comment. In D153960#4455661 <https://reviews.llvm.org/D153960#4455661>, @gribozavr2 wrote:
> Using PointerValue to model pointers to data members does not look right to > me, because a pointer to data member is an offset within an object that we > apply this pointer to, it is not a specific storage location. > > I think we either shouldn't be modeling them at all (current implementation) > and fix any crashes in the downstream code to allow non-modeled constructs in > more places, or we should have a distinct kind of Value for pointers to > members. After some offline discussion, I'll proceed by not modeling pointers to members at all for the time being (i.e. not associating them with a `Value`) but fixing the crashes. Modeling pointers-to-members as a `PointerValue` works to the extent that it allows us to compare different pointers-to-members for equality, but where it breaks down is if we want to dereference them (assuming that we know unambiguously what value the pointer-to-member will have). At that point, what we would probably want is some `MemberPointerValue` that refers to the `Decl` for the field or member function being referenced. I'll ping this patch once it's ready to review again. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153960/new/ https://reviews.llvm.org/D153960 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
