[clang] [clang][ssaf] Implement Entity Linker CLI and patching for JSON Format (PR #184713)

Balázs Benics via cfe-commits cfe-commits at lists.llvm.org
Fri Mar 6 07:45:10 PST 2026


================
@@ -0,0 +1,94 @@
+//===- JSONEntitySummaryEncoding.cpp --------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "JSONEntitySummaryEncoding.h"
+#include "JSONFormatImpl.h"
+
+namespace clang::ssaf {
+
+llvm::Expected<bool> JSONEntitySummaryEncoding::patchEntityIdObject(
+    llvm::json::Object &Obj, const std::map<EntityId, EntityId> &Table) {
+
+  llvm::json::Value *AtVal = Obj.get(JSONEntityIdKey);
+  if (!AtVal) {
+    return false;
+  }
+
+  if (Obj.size() != 1) {
+    return ErrorBuilder::create(std::errc::invalid_argument,
+                                ErrorMessages::FailedToReadEntityIdObject,
+                                JSONEntityIdKey)
+        .build();
+  }
----------------
steakhal wrote:

~~I'm not sure we should treat these as errors. We can't know the content of the summary data. And it might be very well something like this:{ "@": "something", "custom": 3 }Maybe the best is to silently ignore these and only transform perfect matches and just ignore the rest.~~  
  
I think in a general setting, if we have a special symbol like `@` then we should also have an escape for it and escape summary-data that would otherwise match this pattern with the escaped one while encoding.  
Of course for now, we can leave it as-is, but in general it's not the right approach.

https://github.com/llvm/llvm-project/pull/184713


More information about the cfe-commits mailing list