[PATCH] D148949: [dataflow] HTMLLogger - show the value of the current expr
Martin Böhme via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Apr 24 02:53:52 PDT 2023
mboehme added inline comments.
================
Comment at: clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:96
+ for (const auto& Prop : V.properties())
+ JOS.attributeObject(Prop.first(), [&] { dump(*Prop.second); });
+
----------------
IIUC, this places properties on the current HTML element as attributes, just like the built-in attributes that we add for other purposes (e.g. "value_id", "kind").
- What happens if we have a property whose name conflicts with one of the built-in attributes?
- Even if we don't have a naming conflict, I think it could be potentially confusing to have user-defined properties appear in the same list and in the same way as built-in attributes.
Suggestion: Can we nest all properties inside of a "properties" attribute?
Edit: Having looked at the HTML template now, I see that we exclude certain attributes there ('kind', 'value_id', 'type', 'location') when listing properties. I still think naming conflicts are a potential problem though. I think it would also be clearer to explicitly pick the properties out of a `properties` attribute rather than excluding a blocklist of attributes.
================
Comment at: clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:121-123
+ for (const auto &Child : cast<StructValue>(V).children())
+ JOS.attributeObject(Child.first->getNameAsString(),
+ [&] { dump(*Child.second); });
----------------
================
Comment at: clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:122
+ for (const auto &Child : cast<StructValue>(V).children())
+ JOS.attributeObject(Child.first->getNameAsString(),
+ [&] { dump(*Child.second); });
----------------
Same rationale as for properties above: can we nest the fields inside of a `fields` attribute?
I think it would also be useful to distinguish between properties and fields in the HTML output; probably not with another nesting level (yikes!), but just rendered differently. This could easily be done if they were separated into `properties` and `fields` attributes.
================
Comment at: clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp:149
+ case Value::Kind::Biconditional: {
+ auto &VV = cast<ImplicationValue>(V);
+ JOS.attributeObject("lhs", [&] { dump(VV.getLeftSubValue()); });
----------------
================
Comment at: clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp:179
EXPECT_THAT(Logs[0], HasSubstr("LocToVal")) << "has built-in lattice dump";
+ EXPECT_THAT(Logs[0], HasSubstr("\"type\": \"int\"")) << "has value dump";
}
----------------
Can you add some additional tests for the following?
- Pointers
- References
- Properties
- Struct fields
Ideally, other value kinds too (see copy-paste error above for `BiconditionalValue`).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148949/new/
https://reviews.llvm.org/D148949
More information about the cfe-commits
mailing list