Usability improvements in GCC 8(developers.redhat.com)
developers.redhat.com
Usability improvements in GCC 8
https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/
28 comments
[author of the blog post here]
Sadly, gcc 8 isn't smart enough to do that yet; I only implemented it for simple "return name_of_field;" accessors.
But it's an interesting idea, which I've filed as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895 - thanks.
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...)
Sadly, gcc 8 isn't smart enough to do that yet; I only implemented it for simple "return name_of_field;" accessors.
But it's an interesting idea, which I've filed as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895 - thanks.
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...)
thanks for taking time to reply!
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!
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!
Looks like that's too complicated. This is what godbolt.org shows the output at (if you add the missing #include <utility> and pick "trunk" for gcc):
<source>: In function 'void test(foo*)':
<source>:16:16: error: 'int foo::m_x' is private within this context
if (ptr->m_x >= 3)
^~~
<source>:9:11: note: declared private here
int m_x;
^~~
Compiler returned: 1Ever so once in a while, I see stuff like this, remember my C++ days, and feel excited about trying to write more C++… and then I snap out of it, like remembering why you broke up with an ex-lover in the first place.
No, but seriously, this is great stuff, and I am always happy to see gcc get better. The next time I write C++, which I’ll try to do for GNU Octave, I’ll be very grateful for better diagnostics. I already am, since gcc keeps getting better and better.
No, but seriously, this is great stuff, and I am always happy to see gcc get better. The next time I write C++, which I’ll try to do for GNU Octave, I’ll be very grateful for better diagnostics. I already am, since gcc keeps getting better and better.
One improvement I'd like to see is a simplified error message for mismatched overloaded calls. If you make an overloaded call for which the is no matching conversion or if the conversation is ambiguous the compiler will "helpfully" dump a list of possibly matching overloaded function signatures. The list can be hundreds of lines long. For example, when you try to pipe a class to std::cout that doesn't have an std::ostream &operator<<(std::ostream &, const X &).
Perhaps instead of dumping the complete function signatures it could show one function signature followed by a list of types accepted as the second parameter. Since the signatures are otherwise the same. Such improvements could also reduce template error spew.
Perhaps instead of dumping the complete function signatures it could show one function signature followed by a list of types accepted as the second parameter. Since the signatures are otherwise the same. Such improvements could also reduce template error spew.
Thanks; I like that idea.
I've filed it as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
I've filed it as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
The UX of development tools is such an incredibly fundamental thing to fix.
Back in the day it was acceptable to build things without thinking how easy they were to use, indeed being "easy" was somehow a bad thing, like people who used to deride users of Mac OS.
The same applies to development tools, you aren't dumb if your tool is unhelpful, and if it takes 5 seconds less to see a problem, multiply that by how often that problem is encountered around the world, and you're making a significant difference to productivity.
Not to mention developer sanity. Why should designers have nice tools and we get tools that hate us?
Back in the day it was acceptable to build things without thinking how easy they were to use, indeed being "easy" was somehow a bad thing, like people who used to deride users of Mac OS.
The same applies to development tools, you aren't dumb if your tool is unhelpful, and if it takes 5 seconds less to see a problem, multiply that by how often that problem is encountered around the world, and you're making a significant difference to productivity.
Not to mention developer sanity. Why should designers have nice tools and we get tools that hate us?
Fantastic work, I hope this is just the beginning.
Fantastic! My thanks to David Malcolm for this work. I think this will help a lot of people.
These are great investments to make! Keep up the good work!
Thanks! Any ideas for other improvements? (even if it's just fixing "paper cut"-style little annoyances)
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.
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.
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 and hope to fix it in gcc 9.
I've filed this one as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887 and hope to fix it in gcc 9.
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." :)
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." :)
A small idea: reframe suggestions to be positive, future-looking, and pro-active, such as replacing:
did you forget to ‘#include <limits.h>’?
with:
Consider it a path that is the opposite of Nedry's "You didn't say the magic word!"
did you forget to ‘#include <limits.h>’?
with:
do you want to ‘#include <limits.h>’? you may want to ‘#include <limits.h>’.
Consider it a path that is the opposite of Nedry's "You didn't say the magic word!"
Thanks; I like it. I've added that to 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 :)
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 (I hope to improve this in gcc 9)
I've filed this along with some related ideas as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889 (I hope to improve this in gcc 9)
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.
Thanks! I've added the idea to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
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.
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.
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?)
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.
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?
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.
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.
Awesome GSoC project. Well done.
Making C less of a pain, nice
> How do I get at some private field?
That one is interesting! I wonder how smart it is.
For instance in the following example:
I wonder if the compiler would be able to figure out that m_x is accessible via `ptr->get_coordinates().first` ?