================
@@ -91,15 +93,35 @@ class UnsafeBufferUsageEntitySummary final : public
EntitySummary {
: EntitySummary(), UnsafeBuffers(std::move(UnsafeBuffers)) {}
public:
- SummaryName getSummaryName() const override {
- return SummaryName{"UnsafeBufferUsage"};
- };
+ SummaryName getSummaryName() const override { return summaryName(); };
bool operator==(const EntityPointerLevelSet &Other) const {
return UnsafeBuffers == Other;
}
+ bool operator==(const UnsafeBufferUsageEntitySummary &Other) const {
+ return UnsafeBuffers == Other.UnsafeBuffers;
+ }
+
bool empty() const { return UnsafeBuffers.empty(); }
+
+ static llvm::json::Object
+ jsonSerializeFn(const EntitySummary &ES,
+ JSONFormat::EntityIdToJSONFn EntityId2JSON);
+
+ static llvm::Expected<std::unique_ptr<EntitySummary>>
+ jsonDeserializeFn(const llvm::json::Object &Data, EntityIdTable &,
+ JSONFormat::EntityIdFromJSONFn EntityIdFromJSON);
----------------
steakhal wrote:
To some degree, I find the presence of these static member functions here
surprising.
These are implementation details, and the decoupled FormatInfo registration
would enable you to split this from the public-facing header.
I'm not opposing because we haven't settled on a common practice yet, but IMO
this shouldn't be here.
---
I had to think about this, and I think I know why I didn't like this. The whole
premise of the decoupled registration is that we don't know ahead of time what
formats users want to define. Consequently, what serialize/deserialize
functions a Summary will have.
The fact that we spell a specific (albeit "builtin") format breaks this
decoupling. By definition, one must be able to implement the format for a
Summary without touching/opening the specific Summary.
Therefore, I'm against having anything format-related in this public-facing
header.
https://github.com/llvm/llvm-project/pull/187156
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
