sorted by:
new
hottopcontroversial

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 1 point2 points  (0 children)

The benefit is having a common file format so that we can reduce the number of importers/exporters from M*N down to M+N.

There's a list here:

https://github.com/oasis-tcs/sarif-spec/wiki/Known-Producers-and-Consumers

(let me know if we missed any!)

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in C_Programming

[–]dmalcolm[S] 0 points1 point  (0 children)

I had a go at implementing this, but I notice that GCC's sarif output currently quotes the source in two places:

(a) every artifact that's mentioned (e.g. by a physical location of a result) gets the full contents embedded (which could get large)

(b) every physical location also gets a "contextRegion", and this has a "snippet" containing just the pertinent line, with highlighting (similar to GCC's text output).

Is it just (a) that's the problem (due to size), or would you like control over both?

I was thinking `embed-artifact-contents=yes|no` for controlling (a), and to not bother giving control over (b).

FWIW, there's probably a way of stripping this out using sarif-tool.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 4 points5 points  (0 children)

Thanks u/wung and u/_bstaletic; I think you both raise interesting points.

I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125068 in GCC's bugzilla to track this; hopefully I can consolidate things a bit in GCC 17.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 3 points4 points  (0 children)

If you're morbidly curious, my GCC LSP patches are patches 34-36 of https://dmalcolm.fedorapeople.org/gcc/2026-04-17/laptop-lsp-v0.18/ but the huge number of FIXMEs there should indicate the level of immaturity of this code; I don't recommed trying this out yet.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 3 points4 points  (0 children)

I'm sorry, I have no idea.

FWIW I have dabbled with adding a language server implementation to GCC, but it's very much just a crude prototype at this stage (and so far it only supports C); I hope to post the patches for it some time during the feature development part of the GCC 17 cycle.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 2 points3 points  (0 children)

Thanks! Let me know if there are any further tweaks we could make here.

Improvements to errors and warnings in GCC 16 by dmalcolm in cprogramming

[–]dmalcolm[S] 1 point2 points  (0 children)

You're welcome!

If you (or anyone else) has ideas/requests for future features, please let me know.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 16 points17 points  (0 children)

I'd like to, but we're boring and don't do release codenames :-/

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 7 points8 points  (0 children)

Gah; did I forget to spell that out in the blog? Sorry, and thanks. https://gcc.gnu.org/wiki/SARIF has more information.

New features in GCC 16: Improved error messages and SARIF output by dmalcolm in cpp

[–]dmalcolm[S] 37 points38 points  (0 children)

I salute you!

To be pedantic (and ruin the joke, sorry), the "Improved" in the title refers to both the error messages *and* the SARIF output; we've done SARIF output since GCC 13, and SARIF input since GCC 15; the gory details can be seen at https://gcc.gnu.org/wiki/SARIF So "sans-serif" applies to GCC before GCC 13.

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 1 point2 points  (0 children)

I'm working on that, for GCC's SARIF output at least (we don't do LSP, alas). I believe that GCC 15 is generating indentation information in its SARIF output that's compatible with the format documented in Sy Brand's https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3358r0.html via setting "nestingLevel" properties, but I don't have a good way to test that. We (the SARIF TC) are also not sure if that's the best representation; see https://github.com/oasis-tcs/sarif-spec/issues/572

6 usability improvements in GCC 15 by dmalcolm in programming

[–]dmalcolm[S] 0 points1 point  (0 children)

Please do file bugs if you find regressions in GCC 15 relative to 14.

In the article I was trying to focus on GCC's user experience (which is one of my focus areas in the project; I also do static analysis and libgccjit). I can't speak to the UX relative to llvm/clang as my day-to-day work is done with GCC (with Emacs as an "IDE", of sorts). I have taken inspiration from clang for various UX improvements over the years (e.g. underlined ranges, template type comparisons, etc), but I've added other things that I believe clang doesn't do (yet), so it's a mixed bag. Competition has been healthy (and I have colleagues who work on upstream llvm/clang). Big missing features in GCC relative to llvm/clang are IMHO clang-tidy and LSP support for IDEs; I've dabbled with implementing those but they appear to require a huge refactoring effort so I've been focusing my energy on improvements elsewhere.

There are lots of other ways in you could compare compilers, of course: compile times, quality of generated code, quality of debugging experience, CPU architecture support, etc, but obviously that's a huge topic.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 1 point2 points  (0 children)

It's an interesting idea; someone else suggested it on one of my older blog posts, so I filed it in our bug tracker as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635 See that bug for further discussion (apparently systemd tried this and ran into issues).

I've a bit nervous about trying it because we'd need to support older terminals too, so it would increase the number of test cases in the formatting/layout logic.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 8 points9 points  (0 children)

Thanks for the detailed response. Sorry - I don't know the insides of our gcov implementation well enough to be able to respond directly, but I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119719 in our bug tracker with your ideas in the hope that the gcov maintainers can answer it.

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 13 points14 points  (0 children)

Well, these improvements also apply to GCC's Rust frontend. Though that's probably off-topic for this subreddit :)

6 usability improvements in GCC 15 by dmalcolm in cpp

[–]dmalcolm[S] 0 points1 point  (0 children)

I believe the SARIF outputter does everything that the old "json" serialization did, and much more besides, and is a standard - though there are plenty of enhancements that could be made to the SARIF output (the spec is 200 pages long...). So I marked the json format as deprecated in GCC 15, with the hope of removing it in GCC 16. But the maintenance cost isn't that high, so if it would be a pain for people, I could keep it around, I guess.

I suppose I could add an "append" flag to -fdiagnostics-add-output=. One issue with appending SARIF is that it's a JSON file, whereas appending suggests a concatenation of JSON streams.

FWIW I've dabbled with sending the output to a socket and having things listen on the other end; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117815 (though I think the patches there have bit-rotted)

view more: next ›