977 – Expressions inside a struct or array initializer get wrong line number

struct S {
	int[] x;
}
S s =
{
	[
		1, 2, 3,
		4, 5, 6
		7, 8, 9 // error line number should be here (line 12)
	]
} // but is here (line 15)
;
If an array is initialized directly and there's no struct initializer, the line number is reported correctly.

*** Issue 3994 has been marked as a duplicate of this issue. ***

This happens because the parser scans across the whole initializer to determine if it's an expression or an initializer. Because it's already lexed the whole initializer, the lexer's loc points to the end, and this is what is assigned to each expression. Not sure how to solve this without re-lexing the initializer.

(In reply to comment #2)
> This happens because the parser scans across the whole initializer to determine
> if it's an expression or an initializer. Because it's already lexed the whole
> initializer, the lexer's loc points to the end, and this is what is assigned to
> each expression. Not sure how to solve this without re-lexing the initializer.
But it manages to give line numbers for errors that occur in the semantic analysis phase. The D compiler first lexes/parses the entire source file, then semantically analyses it. So it should be able to get this right.
Two ways I can see to do it:
- Remember the line number of every token just in case
- Realise on hitting the 7 that it is no longer parseable as either an expression or an initialiser, and deliver the error there and then.

(In reply to comment #3)
> (In reply to comment #2)
> > This happens because the parser scans across the whole initializer to determine
> > if it's an expression or an initializer. Because it's already lexed the whole
> > initializer, the lexer's loc points to the end, and this is what is assigned to
> > each expression. Not sure how to solve this without re-lexing the initializer.
> 
> But it manages to give line numbers for errors that occur in the semantic
> analysis phase. The D compiler first lexes/parses the entire source file, then
> semantically analyses it. So it should be able to get this right.
> 
It lexes while it parses, so when the parser creates the ast it can use the current location of the lexer instead of storing in the tokens. This is very efficient and works everywhere except when arbitrary lookahead is required.
> Two ways I can see to do it:
> - Remember the line number of every token just in case
As a last resort. This would likely be a performance hit, and complicate the parser code in most places for no benefit.
> - Realise on hitting the 7 that it is no longer parseable as either an
> expression or an initialiser, and deliver the error there and then.
It would have to be parsing to find this error, while it scans it's only lexing.
The relevant code is at 3185 and 3272 in parse.c
The solution is probably to initially parse it one way and convert if wrong, preserving location information, but this might not be possible.

My patch proposal:
https://github.com/p0nce/dmd/commit/bedcd6e7dc43087afdf816cf00debba03aafd400 

Commit pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/dc8b6ea10b4e76cddc0e13119443e286cff6ba6c
Merge pull request #790 from p0nce/master
Bug 977

Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/6f9e42c84fc1d4fdd91d2387fe5bbdf549e8b018
fix Issue 977 - Expressions inside a struct or array initializer get wrong line number