D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 4144 - Better line number of semicolon expected errors
Summary: Better line number of semicolon expected errors
Status: RESOLVED WONTFIX
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2010-05-02 02:37 UTC by bearophile_hugs
Modified: 2021-03-17 14:42 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bearophile_hugs 2010-05-02 02:37:08 UTC
To show how semicolons are namaged by the dmd D2 compiler I have written this hello world program:

import std.stdio;
struct Foo {
    int x, y;
}
int global;
void main() {
    writeln("Hello World");
}


It contains four semicolons, if you remove the first one dmd V.2.043 produces:
test.d(2): ';' expected
test.d(2): no identifier for declarator Foo
test.d(2): semicolon expected, not '{'
test.d(2): Declaration expected, not '{'
test.d(4): unrecognized declaration

If you remove the second one dmd produces:
test.d(4): semicolon expected, not '}'

If you remove the third one dmd produces:
test.d(6): semicolon expected, not 'void'

If you remove the 4th on line 7 dmd produces:
test.d(8): found '}' when expecting ';' following 'statement'


Not even one of those error line numbers point to the line actually missing the semicolon. My editor jumps to the line of the error, so having the right line number saves a bit of my time. Is it possible for dmd semicolon expected error messages to point to the line that misses the semicolon?
Comment 1 RazvanN 2021-03-17 14:42:50 UTC
This issue cannot be fixed because the parser does not have sufficient information to know where the semicolon should be. The positions of the semicolons are the ones that instruct the parser how to interpret statements, therefore if one is missing, the compiler simply considers that it has to continue parsing.

Unfortunately this is a WONTFIX.