Timeline for Are very explanatory compiler error messages worth the effort needed to implement them?
Current License: CC BY-SA 4.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Sep 12, 2023 at 15:10 | history | edited | Ray Butterworth | CC BY-SA 4.0 |
Expand example.
|
Sep 12, 2023 at 15:03 | comment | added | supercat | Another distinction is between compilers which would flag a precise location within a line, versus those that would merely flag a line. Trying to flag a location within a line would work better in languages with more concrete grammars than with others where constructs could mean different things based upon other constructs that could appear later, but something like Turbo Pascal 2.0 and 3.0 diagnostics worked pretty well given the simplicity of their implementation. | |
Jul 1, 2023 at 14:47 | comment | added | Karl Knechtel | If it's possible that the typo was several lines earlier (e.g. because the language permits multi-line parenthesized expressions), the error message should hint at where to start looking. "Line 86, column 23: parenthesis opened at line 54, column 70 should have closed by now." | |
Jul 1, 2023 at 13:05 | comment | added | Ray Butterworth | @JörgWMittag, thanks. I've incorporated that suggestion. | |
Jul 1, 2023 at 13:05 | history | edited | Ray Butterworth | CC BY-SA 4.0 |
Incorporate Jörg W Mittag's suggestion.
|
Jul 1, 2023 at 12:50 | comment | added | Jörg W Mittag | Even worse is that "syntax error at line 86" is often very much not an error at line 86, rather, line 86 is the point where the parser got stuck after blowing past the actual error many lines earlier. | |
May 20, 2023 at 1:43 | comment | added | Bbrk24 | I just ran into this: MSVC "not all control paths return a value" vs clang "enumeration value 'GTI' not handled in switch". | |
S May 19, 2023 at 1:57 | review | First answers | |||
May 19, 2023 at 2:04 | |||||
S May 19, 2023 at 1:57 | history | answered | Ray Butterworth | CC BY-SA 4.0 |