hckrnws
New features in GCC 16: Improved error messages and SARIF output
by siteshwar
by siteshwar
Also, that interactive `-fanalyze`-output with the pointer visualisation looks super handy!
Happy to see there's still focus on the DX in GCC. C and C++ sorely needs it.
After more than 20 years in c++, I gave up that the situation will ever really be fixed vs constantly being made better at the margins, but not as fast as new ideas get added to the language.
https://developers.redhat.com/articles/2026/04/28/gcc-16-imp...
https://developers.redhat.com/articles/2026/04/28/gcc-16-imp...
https://developers.redhat.com/articles/2026/04/28/gcc-16-imp...
I looked into using SARIF once before and found it's an enormous over-engineered design-by-committee spec, but I guess it's still better than regexes (do people really do that?).
Concepts at least tells you which criteria you didn't satisfy (as long as the concept is correct...), which - admittedly - feels like putting a bandaid on bullet wound.
Rust has the same problem as templates with macros. We haven't had a strong need to customize the macrosl evaluation much, but I could very much see us special casing macros that are function like, or have macro arms that can only be a handful of things in order treat them different so diagnostics get better. The only thing that comes to mind thar we do today, is that when a macro call falls through (no macro arm matches), we retry it adding commas in between expressions to see if it was just a typo.
Also, so far I would say they haven't been getting people rushing out to use them anyway, as C++20 is still too new for many projects.
Even GCC only now changed to C++20 as default mode.
Hence why SARIF has seen big adoption, as they hope that by exposing that , there are others ways to have others have tools that process SARIF.
They had a chance in c++11 - we’re going to make a modern c++ that fixes the old problems. And for a time that was true. But they’ve completely lost their way again and getting caught flat footed when the US government recommended people stop using c++ and instead of figuring out how to fix the language they doubled down on unworkable ideas that don’t meaningfully improve the situation.
I think the advice will be to run fil-c in production and then c++ will have an issue as to just what it’s identity is because in practice it will be significantly slower than alternative approaches.
Rust can say hey, this code treats Mallard as if it's a Duck, did you mean for this Mallard to implement Duck? If so, try writing #[derive(Duck)]
But for Concepts Lite the compiler needs to guess that you wanted Mallard to match this requirement that Ducks can quack, and observe that Mallard's quack has a slightly wrong signature so it doesn't match and so that's probably the mistake.
To improve error messages, not so much.
The work in clang and GCC is mostly done by volunteers, big names like Apple and Google rather focus on LLVM itself for their languages.
Microsoft seems to have layed off quite a few people, and is mostly focused on keeping it going for existing projects, in the context of games, as second language paired with .NET, CPython and JavaScript runtimes.
The last framework they published (C++/WinRT), its baseline is C++17, with no plans to upgrade it.
They just released an updated memory model for C# for low level coding that should be competitive with Swift and Rust unsafe models.