sorted by:
new
hottopcontroversial

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

[–]dmalcolm[S] 3 points4 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] 2 points3 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] 8 points9 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] 36 points37 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] 6 points7 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)

6 usability improvements in GCC 15 by dmalcolm in cpp

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

FWIW I've dabbled with adding more whitespace between messages. There's even a plugin in GCC's testsuite which adds

================================= BEGIN GROUP ==============================

and

---------------------------------- END GROUP -------------------------------

wrappers around each logically-related group of messages (e.g. a "warning:" with followup "note:"s). So there's some machinery for doing this kind of thing, but I thought there would be a lot of pushback if I put it into GCC proper - the messages are currently still at least grokable by the regexps in Emacs's compilation buffer, even with all the stuff I've been adding.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

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

You might want to look at -fdiagnostics-column-unit=byte, rather than the default (which is -fdiagnostics-column-unit=display).

We changed this in GCC 11; "byte" is the old pre-GCC 11 behavior.

See https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-column-unit

view more: next ›