This patch adds support for tracking of non-private base-class fields in derived classes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp | ||
|---|---|---|
| 168 | Let's add to the documentation of AggregateStorageLocation and StructValue that they implement a flat struct layout. I don't see an immediate reason to revisit this, but let's be explicit about it. | |
| 182 | The clang namespace is unnecessary. | |
| clang/unittests/Analysis/FlowSensitive/TransferTest.cpp | ||
| 1014 | Add a similar test with class instead of struct? | |
| 1015 | Let's also add private and protected members in A and a private member in B. | |
| clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp | ||
|---|---|---|
| 185 | Will this work well for all cases of diamond shape inheritance? E.g.: struct A { int a; };
struct B : virtual A { int b; };
struct C : virtual A { int c; };
struct D : B, C { int d; };In the above code, I would expect the field a to appear only once. I guess this should work well because of the set representation although we will visit A twice. On the other hand, consider: struct A { int a; };
struct B : A { int b; };
struct C : A { int c; };
struct D : B, C { int d; };Here, in fact, we have 2 instances of the field a. Both B::a and C::a are part of D. I suspect that the current implementation might not handle this. | |
Thanks for the reviews.
| clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp | ||
|---|---|---|
| 185 | Good point, no. But, I'm not sure that fixing this here would be enough - I think we'd also need to revisit how we model structs, since getChild takes a decl as argument -- it doesn't support multiple versions of the same field decl. I added a FIXME since this seems a larger issue, but let me know if you think it needs fixing now. | |
| clang/unittests/Analysis/FlowSensitive/TransferTest.cpp | ||
| 1014 | I went with a simpler test for struct, only verifying that the default is understood correctly (and differently than class), but happy to expand it. | |
| clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp | ||
|---|---|---|
| 185 | I think the argument of getChild needs fixing as well is strong enough to push this to a separate PR. | |
| clang/include/clang/Analysis/FlowSensitive/StorageLocation.h | ||
|---|---|---|
| 59–62 | I find this a bit confusing. StructValue does not contain storage locations in general. I think we should make it clear that the layout of AggregateStorageLocation is flat, i.e. if it's used for a struct or class type it will contain child storage locations for all accessible members of base struct and class types. | |
| clang/include/clang/Analysis/FlowSensitive/Value.h | ||
| 193–194 | I'm not sure what's meant here by indirect reachability, but I suggest documenting that a StructValue that models a struct or class type contains child values for all accessible members of its base struct and class types. | |
| clang/unittests/Analysis/FlowSensitive/TransferTest.cpp | ||
| 1097–1100 | ||
| 1102–1111 | Let's also check FooLoc's child storage locations. Same for the test below. | |
| 1156–1159 | ||
add clarifying comment
| clang/include/clang/Analysis/FlowSensitive/StorageLocation.h | ||
|---|---|---|
| 59–62 | Updated. I misunderstood what you meant as "flat" in the previous round of comments. Thanks for clarifying! | |
I find this a bit confusing. StructValue does not contain storage locations in general. I think we should make it clear that the layout of AggregateStorageLocation is flat, i.e. if it's used for a struct or class type it will contain child storage locations for all accessible members of base struct and class types.