[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