
Usability improvements in GCC 8 - nbsd4life
https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/
======
vmarsy
A 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
[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
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!

------
jordigh
Ever 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.

------
jcoffland
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.

~~~
dmalcolm
Thanks; 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)

------
EvangelistBilly
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?

------
stuaxo
Fantastic work, I hope this is just the beginning.

------
dwheeler
Fantastic! My thanks to David Malcolm for this work. I think this will help a
lot of people.

------
ndesaulniers
These are great investments to make! Keep up the good work!

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

~~~
jancsika
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
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
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." :)

------
krankthat
Awesome GSoC project. Well done.

------
wvlia5
Making C less of a pain, nice

