LWN: Comments on "Improved error reporting for CPython 3.10—and beyond"

Improved error reporting for CPython 3.10—and beyond

nix — Wed, 15 Jun 2022 17:14:58 +0000

> I have never met a (not-Lisp) expansion language that I actually liked. I'm not sure why programmers keep trying to build them.

For TeX it was simply because a typesetting language should have *typesetting text* as its primary purpose: so its primary input should be that text, not function calls or whatever. This more or less forces macro-expansion, or something like it, as a way to get anything but text in there. Ugly as sin, but there you are. :/

Improved error reporting for CPython 3.10—and beyond

cozzyd — Fri, 27 May 2022 02:26:02 +0000

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

Improved error reporting for CPython 3.10—and beyond

bluss — Thu, 26 May 2022 11:53:46 +0000

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

rsidd — Thu, 26 May 2022 11:50:55 +0000

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.

Improved error reporting for CPython 3.10—and beyond

rsidd — Thu, 26 May 2022 04:16:36 +0000

Warnings (like overfull hbox) are not fatal, errors are, unless you like truncated output

Improved error reporting for CPython 3.10—and beyond

willy — Wed, 25 May 2022 14:30:54 +0000

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

MattBBaker — Wed, 25 May 2022 11:59:04 +0000

On the other hand, with latex the errors are not necessary fatal. If the publisher will take it, latex and friends can emit all the exciting errors that they want

Improved error reporting for CPython 3.10—and beyond

dottedmag — Wed, 25 May 2022 09:20:35 +0000

> I'm not sure why programmers keep trying to build them.

Because it's easy to build one.

Bites you (or half of the planet) later on, but still it's easy to build one.

Improved error reporting for CPython 3.10—and beyond

NYKevin — Wed, 25 May 2022 04:55:11 +0000

In my experience, text-expansion (and token/macro-expansion) languages fall into two camps:

* Lisp (and Lisp-likes): I have no experience with it, so I won't state an opinion.
* Not-Lisp: Ranges from bad (e.g. the C preprocessor, bash string expansion) to godawful (e.g. C++ template metaprogramming). LaTeX is somewhere between those two extremes.

I have never met a (not-Lisp) expansion language that I actually liked. I'm not sure why programmers keep trying to build them.

Improved error reporting for CPython 3.10—and beyond

rsidd — Wed, 25 May 2022 04:34:41 +0000

For most physics people I know, the much bigger struggle is with (La)TeX errors. Sometimes they make no sense at all. Python is a breeze in comparison and the particular error shown at the start here would have been flagged by a syntax-highlighting editor.

Improved error reporting for CPython 3.10—and beyond

ballombe — Tue, 24 May 2022 22:06:03 +0000

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

abatters — Tue, 24 May 2022 16:12:16 +0000

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.