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–60 ↗ | (On Diff #419499) | 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 ↗ | (On Diff #419499) | 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–60 ↗ | (On Diff #419499) | Updated. I misunderstood what you meant as "flat" in the previous round of comments. Thanks for clarifying! |
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.