================
@@ -399,21 +412,30 @@ void SarifDocumentWriter::appendResult(const SarifResult
&Result) {
Ret["hostedViewerUri"] = Result.HostedViewerURI;
}
- if (!Result.Locations.empty()) {
- json::Array Locs;
- for (auto &Range : Result.Locations) {
- Locs.emplace_back(createLocation(createPhysicalLocation(Range)));
- }
+ if (!Result.Properties.empty()) {
+ json::Object Properties;
+ for (const auto &[Key, Value] : Result.Properties)
+ Properties[Key.str()] = Value;
+ Ret["properties"] = std::move(Properties);
+ }
+
+ json::Array Locs;
+ for (const auto &Range : Result.Locations)
+ if (std::optional<json::Object> PL = createPhysicalLocation(Range))
+ Locs.emplace_back(createLocation(std::move(PL)));
+ if (!Locs.empty())
Ret["locations"] = std::move(Locs);
+
+ // The schema requires relatedLocations items to be unique.
----------------
zeyi2 wrote:
Thanks for fixing the schema issue! However, deduplicating `relatedLocations`
now drops notes that are legitimately repeated in the regular output.
Reproducer of such cases: https://godbolt.org/z/3oxv171cx
SARIF only keeps the first expanded from macro 'FN' note. The second one
belongs to a different note, so I don't think it is safe to drop it?
Could we assign a unique `id` to each related location instead of deduplicating
them? That would keep repeated notes and still satisfy the `uniqueItems`
requirement for `relatedLocations`.
IMO you can leave it as a follow up if you want.
https://github.com/llvm/llvm-project/pull/219182
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
