On Tue, 26 Jul 2022 at 02:37, Sy Brand via SG15 <sg15_at_[hidden]>
wrote:

> As discussed in the call about P2429
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2429r0.pdf>,
> some of us are going to look into SARIF
> <https://sarifweb.azurewebsites.net/> as a common target for C++ compiler
> error messages.
>
>
>
> I’m going to ask the folks we have looking at SARIF to give their
> thoughts, please do send your own if you have experience with the format,
> or invite relevant colleagues with relevant expertise.
>

GCC trunk supports SARIF as output for diagnostics:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596138.html
https://github.com/oasis-tcs/sarif-spec/issues/531
(The second link has some comments on SARIF from my colleague who
implemented this in GCC.)

One issue he mentioned in the implementation is that SARIF doesn't support
arbitrary nesting:

+/* Handle secondary diagnostics that occur within a diagnostic group.
+ The closest SARIF seems to have to nested diagnostics is the
+ "relatedLocations" property of result objects (SARIF v2.1.0
section 3.27.22),
+ so we lazily set this property and populate the array if and when
+ secondary diagnostics occur (such as notes to a warning). */
+

I'm already unhappy with GCC's one-level nesting, which prevents using two
nesting levels for:

error: no matching call for f(x)
note: candidate f(int, int)
note: <reason candidate isn't viable>

Ideally I want the candidates nested under the error, and the reasons for
failure nested under the candidates.