5 ms·
Usability improvements in GCC 8
- vmarsy 9y agoA lot of good stuff, reading C++ errors is like learning an extra language on top of the C++ language, I can't wait to try it out. > How do I get at some private field? That one is interesting! I wonder how smart it is. For instance in the following example: class foo { public: std::pair<int, int> get_coordinates() const { return std::make_pair(m_x, m_y); } private: int m_x; int m_y; }; void test(foo *ptr) { if (ptr->m_x >= 3) ;// etc } I wonder if the compiler would be able to figure out that m_x is accessible via `ptr->get_coordinates().first` ?
- dmalcolm 9y ago[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 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...)
- vmarsy 9y agothanks 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!
- vidarh 9y agoLooks 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: 1
- ndesaulniers 9y agoThese are great investments to make! Keep up the good work!
- dmalcolm 9y agoThanks! Any ideas for other improvements? (even if it's just fixing "paper cut"-style little annoyances)
- lousken 9y agomaybe an option to print blank lines between errors? the incomplete.c example output would be easier to read/navigate :)
- dmalcolm 9y agoThanks, 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 agoWhat 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 agoThanks! 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 agoA 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.
- jordigh 9y agoEver 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.
- wvlia5 9y agoMaking C less of a pain, nice
- jcoffland 9y agoOne 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.
- dmalcolm 9y agoThanks; I like that idea. I've filed it as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
- dwheeler 9y agoFantastic! My thanks to David Malcolm for this work. I think this will help a lot of people.
- EvangelistBilly 9y agoThe 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?
- stuaxo 9y agoFantastic work, I hope this is just the beginning.
- krankthat 9y agoAwesome GSoC project. Well done.