--- Comment #4 from yebblies <yebbl...@gmail.com> 2012-02-03 12:47:13 EST ---
(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,
> 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
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.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------