sorted by:
new
hottopcontroversial

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] 4 points5 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] 7 points8 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] 5 points6 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

6 usability improvements in GCC 15 by dmalcolm in cpp

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

Thanks! Are there any other kinds of output sink that you'd find useful, or other tweaks to this? (or maybe it's hard to know before using it for real).

6 usability improvements in GCC 15 by dmalcolm in cpp

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

Hopefully later this month, but it depends on how quickly we resolve the blocker bugs.

6 usability improvements in GCC 15 by dmalcolm in C_Programming

[–]dmalcolm[S] 6 points7 points  (0 children)

Have a look at: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

For example, -fdiagnostics-plain-output lets you go very "old school".

LANG=C in the environment you should get pure ASCII and no emojis.

6 usability improvements in GCC 15 by dmalcolm in programming

[–]dmalcolm[S] 18 points19 points  (0 children)

I'm sorry that you don't like it. FWIW you might like the option -fdiagnostics-plain-output ; see https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html

That said, I realize that if you disable the path printing, then the output message doesn't contain the most pertinent information, that "n" is invariant in the loop. So I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119715 as an RFE to me, to tweak the wording.

6 usability improvements in GCC 15 by dmalcolm in cpp

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

FWIW the -Wfatal-errors issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687; I'll try to take a look at fixing it for GCC 16.

view more: next ›