The newly added tests crash without the other changes in this patch.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
Per offline discussion, I think modelling pointer-to-member as PointerValue does make sense, though that's not completely obvious.
Can we document this on PointerValue? (And that it points to a StorageLocation for the decl, which has no value)
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
236 | I'm a bit confused by this. Why bail out rather than create the storage location? C::x is going to be part of &C::x, and we're going to create the storagelocation by calling getStorageLocation() on line 456. So why not do it already? |
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.
clang/lib/Analysis/FlowSensitive/Transfer.cpp | ||
---|---|---|
236 | We can't associate a storage location with *S because it's not a glvalue, and only glvalues are allowed to be associated with storage locations. So we have to defer this work until we get to the & operator. |
Don't produce values for pointers to members. For consistency, also make
the NullToMemberPointer cast not produce any values.
I'm a bit confused by this. Why bail out rather than create the storage location?
C::x is going to be part of &C::x, and we're going to create the storagelocation by calling getStorageLocation() on line 456. So why not do it already?