I'd appreciate dropping red/green as bad/good colorscheme. red & green feed one of the most common visual impairments, and tend to work quite bad with terminal fg/bg colors throughout the spectrum except for its ends (black & white). Maybe you have some color profile descriptor somewhere that a user can change, but a quick search through info gcc (of my installed version) just shows the ability to turn it on & off (-fdiagnostics-color=[auto|never|always]).
Color is definitely one of the things that do NOT work well on a wide variety of terminals. try a white-on-firebrick VTE, or a black-on-darkgoldenrod (awesome for sun-glare, btw), white-on-green, white-on-purple for a change to see how well they mingle...
FWIW I implemented SARIF output in GCC 13, which gives a machine-readable interchange format for the errors. It's viewable by e.g. VS Code (via a plugin). Hopefully that makes it easier to grok the messages.
You can see an example of the output here: https://godbolt.org/z/aan6Kfxds (that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
That doesn't cover the diagrams though (which I currently serialize in SARIF form by making a placeholder Markdown text containing "code" containing the diagram).
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
I've got a few ideas for more general UX improvements with how we do diagnostics, which I'll try in GCC 15 once we're finished focusing on GCC 14 bugfixing.
FWIW I implemented SARIF output in GCC 13 which is viewable by e.g. VS Code (via a plugin) - though the ASCII art isn't.
You can see an example of the output here:
https://godbolt.org/z/aan6Kfxds
(that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
I find that the biggest practical issue with using GCC's analyser is that it's just so darn difficult to set it up and have readable output. Have you considered focusing on this a bit more? Writing documentation (or even producing tools) for integrating analysis into one's usual workflow, integrating with common build systems (e.g. CMake), making the output properly readable in the context of the source code? I feel that at this point this would be much more helpful than ASCII art or more kinds of warnings ...
I did attempt to use the SARIF output just after your previous blog post a year ago, with a CMake based project, but after an hour I still wasn't able get the warnings to show within the context of the source code.
The -fdiagnostics-format option isn't even in the GCC documentation, your blog post is the only place where I saw it mentioned.
In short: I'd love to use GCC's analyser, and tried it several times, but my bottleneck is usability, ease of setup, and a proper interface to help sort out the many false positives from the true issues.
Are there other cases where idiomatic C++ might lead to such an indirect suggestion being appropriate for accessing the field?
(std::tuple, I suppose, but I'm not sure how often that would arise in practice...)
Having some modest compilers knowledge, I'm already impressed that the first use case is possible. It's already covering many uses cases where people use simple Getters, so thanks for the work.
Yes returning std::tuples of an object state or something might be a valid use case, but as you say, I'm not sure how often this would occur!
> q.c:2:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int’
with this:
> q.c:1:6: error: expected ‘;’ before ‘int’
(etc.)
If I were asked to explain why I did not like the old error, I would say it was showing me implementation details about the parser instead of an error aimed at my human brain.
Following that logic, the most human readable error I can think of here would be that we expect a ';' after `int i`. As humans we don't actually care about the next token in the sequence, even if we know the parser had to process it to arrive at the error. That would also eliminate the entire line "int j;".
Otherwise the output is visually confusing-- you have an arrow pointing one's eye to the missing semicolon, but the underlined referent token is two line breaks away from it. Underlining the preceding "i" would put the emphasized token and missing semi right next to each other.
Without knowing much about how compilers work under the hood, its difficult to gauge how ergonomic I can expect them to be while remaining deterministic. If you had told me it's actually NP hard to always select the token before the missing semicolon I would have said, "Oh, ok." :)
Oh, David, it's you! Hah! I didn't realise when I first read the article, didn't see the username.
I just want to thank you again for all of your gcc work. I am so glad when you reached out to us for GNU Octave. How is libgccjit coming along, has it grown?
Edit: Aw, man, you're probably silenced by HN right now. You posted too quickly in succession. Ah well, tell me later about libgccjit.
libgccjit is in maintenance mode: I believe it has everything you need if you (or someone else) wants to implement a JIT for GNU Octave (or for any other interpreter)- I just don't want to be the person to do that, as I have enough on my hands with GCC work; I can't become an Octave maintainer too...
I'm more than willing to help answer questions on it if you or someone else from the GNU Octave community wants to do it (are you doing Summer of Code this year?)
We use a bunch of third party packages (e.g. parts of boost) and, because they typically don't compile without warnings or weird compiler options* we try to isolate them in "trampoline" files or surround the header includes with a bunch of #pragma GCC diagnostic ignored "-Wblahblah"
Some of the errors are way past the parse tree and so they can't be controlled by a pragma diagnostic ignored (e.g. -Wduplicated-branches ). So this option is silently ignored. It would be convenient if GCC could say "Warning: -Wduplicated-branches can't be controlled in a #pragma diagnostic" . (or add support for it, but that's hard :-)
* BTW I'm not implying these warnings are due to crappy programming; typically they result from the wide variety of compilers and C++ standards the library manages to support. I only have to support two compilers on one platform, all in C++17.
Indeed, dealing with multiple configurations with lots of dependencies is hard.
I looked in the option metadata for our C/C++ frontends and
-Wduplicated-branches
isn't flagged as RejectNegative, so
-Wno-duplicated-branches
ought to work; I think you ought to be able to set that on a pragma. Does that help?
-Wno-duplicated-branches is a perfectly reasonable flag for the command line but unfortunately -Wduplicated-branches has no effect when supplied in a #pragma...ignored. Thus my only choice is to have it apply to the entire translation unit.
I understand why this is true and very hard to fix (thus I wouldn't even mention it except you were asking about UI issues rather than code generation issues). But it would be user friendly if GCC could warn of this rather than silently ignoring the flag when using the #pragma...ignored/#pragma...pop model.
By the way there are many such flags that cannot be used in a #pragma...ignored, I just glanced at our source code and grabbed one example at random.
A small idea: reframe suggestions to be positive, future-looking, and pro-active, such as replacing:
did you forget to ‘#include <limits.h>’?
with:
do you want to ‘#include <limits.h>’?
or, perhaps better:
you may want to ‘#include <limits.h>’.
It may seem a small thing, but focusing on the solution
rather than the problem may tend to sooth the mind
of the coder, rather than to magnify their annoyance.
Consider it a path that is the opposite of Nedry's
"You didn't say the magic word!"
What about a line of ─ in between different unassociated errors? So if there is a group of related errors that are about the same actual problem, or a note associated with an error, they're together, but then there's a line of coloured ─ separating them from the next set.
i.e. that's one 700 line test source file, expressing most of the test coverage for one feature.
I realize now that the post should have had an example of what such a test case has; see the "dg-warning" directives in that file.
So that's one "single file" test case. That said, I had to put some of the other test cases for that feature into different test files: some of them interact with the preprocessor in "interesting" ways, so it was simplest to split them out.
However, when a test starts failing, it's handy if the failing test is small (especially when stepping through the latter in the debugger...).
So in our testing we have a mix of both big test files covering a lot of material, and small test files, covering very specific corner cases.
Another aspect of granularity is how long the testsuite takes to run: each test source file in the DejaGnu suite involves exec-ing the compiler, which adds a fixed amount of overhead. It parallelizes well, but it's still advantageous to stuff more testing into fewer files (with the obvious tradeoff w.r.t. debugability if something starts failing). This was another reason for adding the unit-testing suite: this part is all done in-process, and so these ~30,000 tests run in less than a second.
Would I be right in guessing that we're looking at a well-built security system responding to high page load?
Saying the page doesn't exist in these types of situations is interesting. Users consider 404s permanent, so some proportion is unlikely to come back. Furthermore, because each user is hitting the page individually, there's going to be very little out-of-band "no it doesn't work", so it won't reduce server load by much.
From a security standpoint, if high load like this is causing "lp0 on fire"-type issues, a generic 404 may be the correct answer, depending on the situation. A 404 is quite generic, but I'm sure it could still leak useful information depending on the scenario.
Whatever's going on, hearing what actually happened would be very cool (and educational, most people here are Web developers!).
It seems to be working again. Sorry about the snafu. I've been exchanging emails with the team on the hosting side, but I don't yet have info on what happened.
In case it's useful, some of the page resources were 503ing/404ing before:
http://i.imgur.com/5JUyphf.png (the intermixed connection_refused errors are from my /etc/hosts blocking)
More details here: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Format...
I hope my choices here work well on a wide variety of terminals.