5 ms·

Thanks! Any ideas for other improvements? (even if it's just fixing "paper cut"-style little annoyances)

lousken 9y ago
maybe an option to print blank lines between errors? the incomplete.c example output would be easier to read/navigate :)
- dmalcolm 9y ago
  Thanks, that would indeed break up the "wall of text" effect. I've filed this along with some related ideas as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 (I hope to improve this in gcc 9)
  - earenndil 9y ago
    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.
    - dmalcolm 9y ago
      Thanks! I've added the idea to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
jancsika 9y ago
A bit picky but I think it's useful: You improved this: > 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.
- dmalcolm 9y ago
  Thanks - a few other people pointed this out, and I agree. I've filed this one as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 and hope to fix it in gcc 9.
  - jancsika 9y ago
    Great! 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." :)
jordigh 9y ago
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.
- dmalcolm 9y ago
  Hi Jordi! 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?)
gumby 9y ago
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.
- dmalcolm 9y ago
  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?
  - gumby 9y ago
    -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.
dmckeon 9y ago
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!"
- dmalcolm 9y ago
  Thanks; I like it. I've added that to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890

maybe an option to print blank lines between errors? the incomplete.c example output would be easier to read/navigate :)

dmalcolm 9y ago
Thanks, that would indeed break up the "wall of text" effect. I've filed this along with some related ideas as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 (I hope to improve this in gcc 9)
- earenndil 9y ago
  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.
  - dmalcolm 9y ago
    Thanks! I've added the idea to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889

jancsika 9y ago

A bit picky but I think it's useful: You improved this: > 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.

dmalcolm 9y ago
Thanks - a few other people pointed this out, and I agree. I've filed this one as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 and hope to fix it in gcc 9.
- jancsika 9y ago
  Great! 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." :)

jordigh 9y ago

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.

dmalcolm 9y ago
Hi Jordi! 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?)

gumby 9y ago

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.

dmalcolm 9y ago
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?
- gumby 9y ago
  -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.

dmckeon 9y ago

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!"

dmalcolm 9y ago
Thanks; I like it. I've added that to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84890