Malcolm: Usability improvements in GCC 8 [LWN.net]

Over on the Red Hat Developer Program blog, David Malcolm describes a number of usability improvements that he has made for the upcoming GCC 8 release. Malcolm has made a number of the C/C++ compiler error messages much more helpful, including adding hints for integrated development environments (IDEs) and other tools to suggest fixes for syntax and other kinds of errors. "[...] the code is fine, but, as is common with fragments of code seen on random websites, it’s missing #include directives. If you simply copy this into a new file and try to compile it as-is, it fails. This can be frustrating when copying and pasting examples – off the top of your head, which header files are needed by the above? – so for gcc 8 I’ve added hints telling you which header files are missing (for the most common cases)." He has various examples showing what the new error messages and hints look like in the blog post.

to post comments

GCC8 the code patching A.I.

Posted Mar 16, 2018 0:00 UTC (Fri) by mjw (subscriber, #16740) [Link] (18 responses)

Sweet. If you just trust the suggestions gcc makes then you can just generate a patch with -fdiagnostics-generate-patch

/opt/local/install/gcc/bin/gcc -fdiagnostics-generate-patch -g -O2 -o t t.c 2>&1 | patch
patching file t.c

and then the next build will just work (assuming you didn't make more errors).

Given my typo rate this probably should be a default automake rule so gcc patches my sources till they are OK :)

GCC8 the code patching A.I.

Posted Mar 16, 2018 8:17 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

Haha, exactly my thoughts!

so there are still people...

Posted Mar 16, 2018 11:58 UTC (Fri) by HelloWorld (guest, #56129) [Link] (16 responses)

...who use an editor without on the fly syntax checking and code completion? Why would you do that?

so there are still people...

Posted Mar 16, 2018 12:29 UTC (Fri) by Sesse (subscriber, #53779) [Link] (5 responses)

Because it's nice to be able to code without being disturbed.

I generally leave on-the-fly syntax checking on since it shortens build cycles, but turn off automatic code completion (I invoke it manually every now and then, but I typically limit it to tab-completing long names). It's nice to have an continuous stream of thoughts down to the file, as opposed to having a two-way conversation with your editor, which means you need to keep reacting to what it tells you.

so there are still people...

Posted Mar 16, 2018 14:37 UTC (Fri) by raegis (subscriber, #19594) [Link] (4 responses)

Quote: "Because it's nice to be able to code without being disturbed."

I have not heard a more profound statement all year! Those "helpers" are mostly distractions since they constantly provide hints when you rarely need them. Most of my programming is 95% pen and paper anyway.

so there are still people...

Posted Mar 16, 2018 15:28 UTC (Fri) by halla (subscriber, #14185) [Link] (2 responses)

Ha, yes! Today I experimentally enabled the clang plugin in QtCreator. _While_ I was typing a line of code it already nattered at me about a missing semicolon... I know there wasn't one, I wasn't done typing, interfering busybody!

so there are still people...

Posted Mar 16, 2018 15:37 UTC (Fri) by Sesse (subscriber, #53779) [Link]

Just to be clear, I do find in-editor syntax checking a reasonable tradeoff, even though it is sometimes disturbing. It helps that I use vim, where the modality gives reasonably good signals to the editor when it can start trying to compile my stuff (when I exit insert mode).

Also, semantic understanding of the code yields _incredibly_ much better jump-to-definition navigation, which is a huge win, but you don't need to enable any warnings for that, of course.

so there are still people...

Posted Mar 16, 2018 17:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Try something more polished, like any IDE from JetBrains.

so there are still people...

Posted Mar 16, 2018 15:29 UTC (Fri) by Wol (subscriber, #4433) [Link]

And often I find that I type (and *want*) HALF of what *it* thinks I want, so when I hit return at the end of the line it fills in the extra stuff I didn't ask for ...

There's a very good reason I usually call that sort of stuff "auto-CORRUPT".

The problem is, it never seems to stay disabled - that is if I can even find out HOW to disable it :-(

Cheers,
Wol

so there are still people...

Posted Mar 16, 2018 13:01 UTC (Fri) by Paf (subscriber, #91811) [Link] (8 responses)

Lots of folks! I do kernel development, for example, and most IDEs are constantly low level furious about various aspects of it. For starters, they don’t seem to understand the program structure of a kernel module, and it’s horrible to try to get them to build it.

It’s also probably somewhere between horrible and impossible to get them to not get confused by arch-specific definitions, and they generally can’t understand inline assembly at all, so forget that.

So code completion kinda doesn’t work, and you can’t build, oh and the kernel codebase is too large for most IDEs to hold all of it without bogging down.

I miss having syntax checking and code completion, but only moderately.

I also tend - like most kernel developers, I think - to produce relatively few lines of code. (Few but high effort.). That makes the burden of not having such aids much smaller than if you’re writing up whole big chunks of new stuff.

I’m pretty sure my perspective is typical (though not universal...) in the kernel community, based on what I’ve heard and what my coworkers do.

so there are still people...

Posted Mar 17, 2018 7:08 UTC (Sat) by darwish (guest, #102479) [Link] (7 responses)

Sorry but this is nonsense.

I use Eclipse daily for kernel development, and in the last 3 years have been actually maintaining this semi-official wiki page for how to do that:

https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Li...

After doing the steps above, Eclipse indexes everything as need be for the kernel C99 "free-standing" environment, without errors or any nonsensical warnings. You got all the goodies of auto-complete, automatic global refactoring capabilities, semantic code search, code-followup up to the deepest levels of the kernel, etc.

And the performance is quite good, even on a 5-year old HDD laptop.

so there are still people...

Posted Mar 17, 2018 13:15 UTC (Sat) by Paf (subscriber, #91811) [Link] (6 responses)

That’s very interesting, when I tried a few years ago, it shat bricks because the Java implementation was too slow. It was utterly unusable. I had a few coworkers who used to go to the trouble to use it, but my understanding is they’ve mostly given up out of irritation with issues like those I cited and also speed. Glad to hear you’ve worked around them.

Also, I don’t think you’d say it’s nonsense that most kernel developers don’t use an IDE. Or if you did, I think it’d be easy to find references showing that’s wrong,

so there are still people...

Posted Mar 18, 2018 6:06 UTC (Sun) by PengZheng (subscriber, #108006) [Link] (5 responses)

Eclipse CDT is simply the best IDE for open source C/C++ projects (at least for embedded linux development), provided you have enough memory (>= 16G) and a decent CPU installed. Have a look at how it fits to large C/C++ projects other than Linux kernel:

https://chromium.googlesource.com/chromium/src/+/lkcr/doc...
https://developer.mozilla.org/en-US/docs/Mozilla/Develope...

so there are still people...

Posted Mar 18, 2018 18:22 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

Have you tried CLion?

so there are still people...

Posted Feb 19, 2019 6:15 UTC (Tue) by PengZheng (subscriber, #108006) [Link]

I have not, but would like to have a try.

so there are still people...

Posted Mar 18, 2018 23:47 UTC (Sun) by Paf (subscriber, #91811) [Link] (2 responses)

Ah, so “enough memory” is an amount that only stopped being absurd in the last two years or so, and is still double what standard desktops ship with. No wonder it didn’t work well on my six year old work PC.

Every other Linux coding tool I use doesn’t care what hardware I give it as long as it’s got a desktop class CPU (ie is not a Rasberry Pi or similar). 16 GB is totally reasonable for a heavy duty development workstation, but it’s still quite a bit of RAM...

so there are still people...

Posted Mar 21, 2018 7:56 UTC (Wed) by jezuch (subscriber, #52988) [Link] (1 responses)

> 16 GB is totally reasonable for a heavy duty development workstation

I thought that as well. My company's procurement though this too. Unfortunately I'm doing Java at work :) Between all the dev tools (I had to increase the heap space for the IDE to fit all the projects I'm working on), the test instances, the million browser tabs with documentation, there's precious little space left for Virtualbox that is needed to communicate with the rest of the company via a certain "enterprise grade" teleconferencing software with an annoyingly proprietary protocol.

But I manage ;)

so there are still people...

Posted Mar 22, 2018 14:04 UTC (Thu) by Wol (subscriber, #4433) [Link]

And yet 16GB wasn't that expensive ...

I know RAM prices yoyo, but I was lucky and maxed out my motherboard with 4x4GB DDR3 about 5 years ago at about £13/DIMM. £60 for the lot ...

I now want to max out my new mobo but 4x16GB DDR4 at £150/DIMM is a bit much!

Cheers,
Wol

so there are still people...

Posted Mar 17, 2018 13:03 UTC (Sat) by dskoll (subscriber, #1630) [Link]

I use an editor like that. It's just my style and a matter of preference; I don't want my editor mucking about with my text.

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 14:15 UTC (Fri) by ledow (guest, #11753) [Link] (9 responses)

Finally some sense in a compiler output.

It was understandable back in the day for things like "Syntax error on line 3". That was enough to go on, a decent human could track the error down, and your compiler was tiny and efficient.

Nowadays? Sorry, but there's no excuse. Let's spend some of that precious time and deep tree-making analysis to actually pinpoint the problem, why it's there, and take a stab at the most likely fix (e.g. if(a = b) should suggest correction to ==, etc.)

My favourite GCC error that I've received in real life was this:

expected 'struct Player *' but argument is of type 'struct Player *'

Nope. Don't spend ages looking for the wrong space or fancy Unicode or something. It complained because one file defined struct Player one way, and another another way. And because of the way it was done, there were no compilation errors until you get this, because it only sees the wrong definition (so it doesn't warn you of a double-definition anyway). And obviously, in any IDE, when you click on the struct it takes you to the definition that you expect and you're baffled why it does that. Maybe only for a minute or two, or only if you have certain flags turned on (I think it was -Wall -Werror, but whatever), but I loved that message so much I screenshot it.

I'm still waiting for the day when the compiler / application / OS not only flags errors but YOU TELL IT what was wrong and it tries to correct in future from that. Imagine that. An application does something you don't want. You click on the little ? button in the window. You point it at the thing that's wrong (the button that isn't enabled, the field that's greyed out, the wrong size listed for a file, the inaccessible path on the filesystem, etc.) It asks you what's wrong, you select from some options and tell it what you EXPECT to have happened. And then it tells you why. "That button is disabled because this checkbox isn't ticked." "You can't press submit because the two password fields don't match".

In a way, you could make an entire programming language based on that. Start with a blank sheet. Query it. When it asks what you expect, draw a button on the screen. It now knows to draw a button. Now click the button. Nothing happens. Click the ? and point at the button. Scroll back through all the mouse moves and clicks it detected. What were you expecting on the button click? The *dropdown select* colour of this *click* window to turn *click* this colour. Now it does it.

Of course, it would be limited but I'm honestly waiting for a system that's based more on what the user wants/expects than what the designer intended. Where you say "No, you did that wrong" and then correct it.

It would make a nice basis for AI training (if you believe that'll be viable this century) but also it should be possible to say "Well, this bit of code says no, and the reason it says no is because of this condition, and the user obviously isn't aware of the condition".

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 19:04 UTC (Fri) by ballombe (subscriber, #9523) [Link] (4 responses)

> In a way, you could make an entire programming language based on that. Start with a blank sheet. Query it. When it asks what you expect, draw a button on the screen. It now knows to draw a button. Now click the button. Nothing happens. Click the ? and point at the button. Scroll back through all the mouse moves and clicks it detected. What were you expecting on the button click? The *dropdown select* colour of this *click* window to turn *click* this colour. Now it does it.

Congrats, you invented smalltalk!

Malcolm: Usability improvements in GCC 8

Posted Mar 17, 2018 13:03 UTC (Sat) by orsayman (guest, #123153) [Link] (3 responses)

> Congrats, you invented smalltalk!

I was about to say the same thing ! Those smallatalkers do amazing things (like debugging Python code inside Smalltalk).

Malcolm: Usability improvements in GCC 8

Posted Mar 17, 2018 14:34 UTC (Sat) by ledow (guest, #11753) [Link] (2 responses)

Really? I don't think the below has any correlation whatsoever with my description.

exampleWithNumber: x
| y |
true & false not & (nil isNil) ifFalse: [self halt].
y := self size + super size.
#($a #a "a" 1 1.0)
do: [ :each |
Transcript show: (each class name);
show: ' '].
^x < y

Maybe we have "programmer-syndrome" again, like whoever originally did the error messages for gcc, where because it's technically possible to figure out what's going on that must be good enough?

Malcolm: Usability improvements in GCC 8

Posted Mar 18, 2018 2:59 UTC (Sun) by nivedita76 (subscriber, #121790) [Link]

This from the wiki page:
An example of how Smalltalk can use reflection is the mechanism for handling errors. When an object is sent a message that it does not implement, the virtual machine sends the object the doesNotUnderstand: message with a reification of the message as an argument. The message (another object, an instance of Message) contains the selector of the message and an Array of its arguments. In an interactive Smalltalk system the default implementation of doesNotUnderstand: is one that opens an error window (a Notifier) reporting the error to the user. Through this and the reflective facilities the user can examine the context in which the error occurred, redefine the offending code, and continue, all within the system, using Smalltalk-80's reflective facilities.[23][24]

Malcolm: Usability improvements in GCC 8

Posted Mar 26, 2018 5:23 UTC (Mon) by Kamilion (subscriber, #42576) [Link]

Here, this video might help.

https://www.youtube.com/watch?v=AnrlSqtpOkw&t=137s

A retrospective on what smalltalk could do in the mid 70s.

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 14:50 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

It's not just GCC that generates errors like that, of course. A month or so ago I spent some time fixing this utterly mystifying DTrace error message:

translator member pr_fname definition uses incompatible types : "char [16]" = "char [16]"

Er, yeah, right, that explains everything! The actual error was that one "char" was actually "char on a system where char == unsigned char" and the other was a signed "char" since the system was mistakenly assuming that char is always signed -- so the types were not identical, but of course the internal signedness of char is not being printed out in random error messages...

(Of course this was an error in an *implementation*. If a legitimate user got this error, it would be a sign that someone, probably me, had screwed up.)

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 17:19 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

In C, "char", "signed char", and "unsigned char" are all three distinct types. "char" may or may not be signed, but it is not 100% replaceable with the explicit variants.

See this[1] SO answer.

[1]https://stackoverflow.com/questions/75191/what-is-an-unsi...

Malcolm: Usability improvements in GCC 8

Posted Mar 21, 2018 14:31 UTC (Wed) by nix (subscriber, #2304) [Link]

Yes indeed: I kind of assumed that knowledge from the readers. This was a bug in implementation code that was erroneously assuming the identity of char and signed char, and fell over when ported to a platform in which the C char type was unsigned.

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 15:04 UTC (Tue) by nix (subscriber, #2304) [Link]

It would make a nice basis for AI training (if you believe that'll be viable this century) but also it should be possible to say "Well, this bit of code says no, and the reason it says no is because of this condition, and the user obviously isn't aware of the condition".

This sort of thing ("saliency detection") is pretty routine now, at least for spotting overfitting and acting as a guide to figure out why your network is going nuts. You train a network to analyze the state of the target network so it can discern what the other network considers most important in some input, then look at that. (Another way to do it is to have the saliency-detection system repeatedly perturb the input to the target system in some minor way, see if its output changes, then report the regions where perturbations caused the output to change.)

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 15:01 UTC (Fri) by deater (subscriber, #11746) [Link] (1 responses)

There is some creepy "reflections on trusting trust" style stuff going on here.

So now I don't only have to worry about a backdoor in the compiler silently changing generated binaries, now I have to worry about the "auto-correct" auto-correcting the source to introduce subtle backdoors?

It looks like it's back to coding in raw 6502 machine language for me, I can't take the future.

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 20:53 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

You must not be understanding something. Nothing here automatically changes your code. You have the optional ability to generate a patch that makes the change the compiler believes should be made, and and it is up to you to apply it.

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 15:17 UTC (Fri) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

-fdiagnostics-show-template-tree looks useful, but if it's not enabled by default, nobody will be using it. That's a shame.

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 15:53 UTC (Fri) by sjfriedl (✭ supporter ✭, #10111) [Link]

*Lots* of people will enable this because they want it and are prepared to deal with the inevitable bugs, so it will get plenty of miles on it before it's (eventually) turned on for everybody.

Malcolm: Usability improvements in GCC 8

Posted Mar 22, 2018 4:32 UTC (Thu) by ncm (guest, #165) [Link] (2 responses)

I would like it to suggest alternatives to comparing signed with unsigned values. Too often I see people add a cast, or change the type of a variable, when 9 times out of 10, changing < to != is the better choice. (In C and, still, in C++, (-1 < 0u) is false, hence the warning. But the C++ people have vowed to fix it someday -- most likely c. 2029.)

By the way, the compiler people say "for (int i =..." is much better, nowadays, than "for (size_t i =...", although of course "for (auto val : ..." or "std::foreach(..." is better than either.

Malcolm: Usability improvements in GCC 8

Posted Mar 23, 2018 14:44 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

By the way, the compiler people say "for (int i =..." is much better, nowadays, than "for (size_t i =...", although of course "for (auto val : ..." or "std::foreach(..." is better than either.

The latter two are not C, so I guess they are better in the eyes of a C++ fan.

Concerning "for (int i=...", this introduces sign-extension operations when using i for array indexing when compiling for AMD64 with -fwrapv (which is needed for a lot of production code); using long instead of int is one way to solve this if you don't expect i to wrap around.

Alternatively, this problem is also solved by using size_t (if the code is correct for size_t, which it presumably is if it started out with size_t), so suggesting that users replace size_t with int makes no sense (except if a compiler maintainer wants to justify the adversarial default of -fno-wrapv by first getting the user to pessimize his program, and then using this default to undo the pessimization).

Malcolm: Usability improvements in GCC 8

Posted Mar 24, 2018 16:59 UTC (Sat) by zlynx (guest, #2285) [Link]

If the for loop has explicit, understandable termination conditions there's no problem using size_t. GCC as far as I can tell compiles the loop the same way for int or size_t. And size_t is always better because it won't fail like int on unusually large indexes.

So yeah, just use size_t.