[Bug sarif-replay/123056] sarif-replay's HTML output mangles event cross-references in execution paths
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Jan 20 17:11:16 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123056
--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:
https://gcc.gnu.org/g:25910642d367097d19ea90fb2b54e2858ddd74b9
commit r16-6931-g25910642d367097d19ea90fb2b54e2858ddd74b9
Author: David Malcolm <dmalcolm@redhat.com>
Date: Tue Jan 20 12:06:12 2026 -0500
sarif-replay: skip "sarif:/" embedded links [PR123056]
PR sarif-replay/123056 notes that when using sarif-replay to generate
HTML from a .sarif file containing an embedded "sarif:/" link we get
bogus output containing SGR codes.
The links in question come from GCC's sarif output for cross-referencing
event IDs within an execution path.
These links are JSON pointers. I experimented with propertly supporting
the JSON Pointer spec (RFC 6901) within GCC, and I have a partially
working implementation which parses JSON pointers here, and, where
appropriate, reconstructs the pertinent event ID.
However, that feels too invasive to be pushing in stage 4. Hence for
GCC 16, this patch simply skips the link part of "sarif:/" links in
sarif-replay, avoiding corrupt output, deferring the more ambitious
round-tripping fix to GCC 17.
gcc/ChangeLog:
PR sarif-replay/123056
* libsarifreplay.cc (struct embedded_link): Move decl earlier.
(sarif_replayer::append_embeddded_link): New.
(sarif_replayer::make_plain_text_within_result_message): Move the
link-replay logic to the above, and skip the link part of
intra-sarif links.
gcc/testsuite/ChangeLog:
PR sarif-replay/123056
* sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links-pr123056.sarif:
New test.
*
sarif-replay.dg/2.1.0-valid/embedded-links-pr123056-check-html.py:
New test script.
*
sarif-replay.dg/2.1.0-valid/embedded-links-pr123056-check-sarif-roundtrip.py:
New test script.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
More information about the Gcc-bugs
mailing list