Improved error reporting for CPython 3.10

Improved error reporting for CPython 3.10—and beyond

Posted May 24, 2022 16:12 UTC (Tue) by abatters (✭ supporter ✭, #6932)
Parent article: Improved error reporting for CPython 3.10—and beyond

In C, the thing that always gets me:

Forget to add the semicolon after a function prototype in a header file, and gcc spews pages and pages and pages of error messages. Multiplied by the number of parallel jobs in the Makefile.

I just tried it. Deleted one semicolon after a prototype in a header file, ran make -j24, and got literally 185,000 lines of errors.

to post comments

Improved error reporting for CPython 3.10—and beyond

Posted May 24, 2022 22:06 UTC (Tue) by ballombe (subscriber, #9523) [Link] (2 responses)

This is a gcc limitation. The compiler I used before gcc (so before 1994) did not do that, it would say "semicolon expected". I remember because I was a C beginner then and made tons of syntax errors.

Improved error reporting for CPython 3.10—and beyond

Posted May 26, 2022 11:53 UTC (Thu) by bluss (guest, #47454) [Link] (1 responses)

You could call it a "feature". It's a feature to be able to continue past an error and still do an effort to report further errors in the compilation. Sometimes this is even useful - if the errors are independent, you can read them and fix all in one turn of the edit-compile cycle. Unfortunately, if nonsensical knock-on errors are reported, then the end result is less useful.

Rustc early in it development used to be really nice. It's always been good at reporting clear error messages, and it's still doing that well. Unfortunately during its development it's also become a more advanced compiler, and is now very "good" at continuing to compile and report more errors. Again, this sometimes creates lots of nonsensical knock-on errors that are useless to the user. So Rustc grew up and joined GCC in this problem area.

Of course we need to nudge beginners to learn to always look at the first error from the compiler, not the last one (the last one is usually the one remaining in view, unfortunately.)

Improved error reporting for CPython 3.10—and beyond

Posted May 27, 2022 2:26 UTC (Fri) by cozzyd (guest, #110972) [Link]

It's also easy to limit the number of errors printed in gcc.

Improved error reporting for CPython 3.10—and beyond

Posted May 25, 2022 14:30 UTC (Wed) by willy (subscriber, #9762) [Link] (1 responses)

I did persuade the GCC developers that they don't need to continue to parse and emit syntax errors in the main file once there's an error in a header file.

But yes, GCC could be an awful lot better. The example I just hit was a missing function declaration, which happens to return a pointer. GCC emits two errors; the first for an implicit declaration and the second that we're making a pointer from an integer (because the implicit declaration has return type int). The second warning isn't useful.

Easy reproducer:
void *f(void) { return g(); }

A good language would infer the type that g() must return. C is not a good language.

Improved error reporting for CPython 3.10—and beyond

Posted May 26, 2022 11:50 UTC (Thu) by rsidd (subscriber, #2582) [Link]

gcc 11.2 still thinks the error is in the main file. Perhaps fixed it in gcc12? I tried it with a one-line header include missing a semicolon. With gcc11

$ gcc -c test.c
test.c: In function ‘printhello’:
test.c:3:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
    3 | int main() {
      |            ^
test.c:6: error: expected ‘{’ at end of input

With clang

$ clang -c test.c
In file included from test.c:1:
./printhello.h:1:18: error: expected ';' after top level declarator
void printhello() 
                 ^
                 ;
1 error generated.

However, I tried a more complicated codebase, and I don't get pages of errors: it errors out right after it figures out there is no opening brace or semicolon after the function definition.