On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
> On 9/22/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > Except that most of us don't care about the column number. It's of
> > marginal
> > benefit at best, and it harms compilation speed, so it's not worth it
> > IMHO.
> 
> You've never ran into lexer errors before have you?
> 
> test.d(10): Error: found ',' when expecting ')'
> 
> Now good luck finding where you forgot to put a closing brace in a statement that uses traits or is(typeof( checks, such as this:
> 
> static assert(0, format("%s does not implement '%s'",
> __traits(identifier, typeof(this))), __FUNCTION__);
> 
> It should have been:
> 
> static assert(0, format("%s does not implement '%s'",
> __traits(identifier, typeof(this)), __FUNCTION__));
> 
> That's just a trivial case though.
> 
> I run into these all the time, and I have to spend half a minute scanning left and right trying to figure out where the damn missing brace went. Marginal benefit my ass.

Except that because the compiler doesn't know where the terminator should have been, it can't give you a column number anyway. In that case, it can't even give you the correct line number. At best, it can tell you the line number where the unmatched symbol was, and that's often not helpful (especially with braces). And even with parens, because the compiler doesn't know what you actually meant to do, it's not like it can tell you where exactly in the expression or statement you need to fix your code anyway. I really don't think that a column number would help much here.

- Jonathan M Davis

On Sunday, 22 September 2013 at 21:12:22 UTC, Jonathan M Davis wrote:
> On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
>> On 9/22/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> braces). And even with parens, because the compiler doesn't know what you
> actually meant to do, it's not like it can tell you where

Maybe, but at least it can say: HERE, you see, HERE, this is the exact place where I was expecting a ')' and found a ','. I mean, HERE means the third comma on this line, not the second, not the fifth.

It is an important information when you have a LOC with 10 ')' and 20 commas.

Which comma is the trouble?

On 9/22/2013 2:17 PM, eles wrote:
> It is an important information when you have a LOC with 10 ')' and 20 commas.

Fortunately, D is not Lithp :-)

On 22 September 2013 20:27, Walter Bright <newshound2@digitalmars.com> wrote:
> On 9/22/2013 11:43 AM, Timon Gehr wrote:
>>
>> Tracking line numbers is likely worth it. I don't believe that providing
>> column
>> numbers in error messages necessitates a slowdown though.
>
>
> Please consider that:
>
>      IT ISN'T JUST FOR ERROR MESSAGES
>
> It would go in the symbolic debug info, too, where it will be required everywhere and will be right there on the fast path through the lexer/compiler.
>
> Now consider the lexer doing a fast skip over comment text (this ranks fairly high in the profile). This operation gets a lot slower if you're also keeping track of column number. Please note that:
>
>      COLUMN NUMBER ISN'T THE OFFSET FROM THE START OF THE LINE
>
> because of tabs and UTF-8 sequences.
>
> Any proposal for column number tracking must take these issues into account.
>
> Also note that g++ and clang are hardly noted for their fast compile speeds. Also note that g++'s compile speed has dropped significantly lately - I don't know why, but it also added column number support recently (!).

Depends on what you mean by "recently".  GCC has certainly gained a fair few compilation/optimisation passes over the past few releases.

4.3 - 223 passes  (2008)
4.4 - 225 passes  (2009)
4.5 - 239 passes  (2010)
4.6 - 241 passes  (2011)
4.7 - 252 passes  (2012)
4.8 - 268 passes  (2013)
4.9 - 269 passes  (development)

And showing column numbers has been turned on since gcc-4.4 (released in 2009).


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 9/22/2013 10:43 AM, Walter Bright wrote:
> On 9/22/2013 10:16 AM, Mike Wey wrote:
>> I've reduced the code causing the error to this:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11101
>

Upon looking at it more closely, the bug is invalid, and the compiler is correct. See the report for the explanation.

On 23/09/13 07:12, Jonathan M Davis wrote:
> On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
>> On 9/22/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>>> Except that most of us don't care about the column number. It's of
>>> marginal
>>> benefit at best, and it harms compilation speed, so it's not worth it
>>> IMHO.
>>
>> You've never ran into lexer errors before have you?
>>
>> test.d(10): Error: found ',' when expecting ')'
>>
>> Now good luck finding where you forgot to put a closing brace in a
>> statement that uses traits or is(typeof( checks, such as this:
>>
>> static assert(0, format("%s does not implement '%s'",
>> __traits(identifier, typeof(this))), __FUNCTION__);
>>
>> It should have been:
>>
>> static assert(0, format("%s does not implement '%s'",
>> __traits(identifier, typeof(this)), __FUNCTION__));
>>
>> That's just a trivial case though.
>>
>> I run into these all the time, and I have to spend half a minute
>> scanning left and right trying to figure out where the damn missing
>> brace went. Marginal benefit my ass.
>
> Except that because the compiler doesn't know where the terminator should have
> been, it can't give you a column number anyway. In that case, it can't even
> give you the correct line number. At best, it can tell you the line number
> where the unmatched symbol was, and that's often not helpful (especially with
> braces). And even with parens, because the compiler doesn't know what you
> actually meant to do, it's not like it can tell you where exactly in the
> expression or statement you need to fix your code anyway. I really don't think
> that a column number would help much here.

With my dunnart LALR(1) parser generator, the lexer that's generated as part of the generated parser passes its tokens as class instances that give access to the line number and column at which the token was found in the text and the exact slice of the input text that was matched to form the token.  That information travels with the token (rather than being something you have ask the lexer for in most lexers e.g. flex) so it's always available no matter where the token pops up in the parser.

Similarly, when the parser does a reduce, the non terminal grammar symbol acquires the positional data for the first token in the reduced sequence.

Peter

On 2013-09-21 21:47, Walter Bright wrote:

> That's gcc, and 4 is the line number (and the wrong line number) of the
> error. No column number.

It's time you start using clang instead of gcc.

-- 
/Jacob Carlborg

On 2013-09-22 07:22, Walter Bright wrote:

> I'm not rejecting the idea outright. I've actually implemented this in
> the dmc compiler. It's just not terribly useful, and it has costs.

Several people has asked for it and the LLVM community thinks it's worth it.

-- 
/Jacob Carlborg

On 2013-09-22 04:38, Paul Jurczak wrote:

> That would do: 255 means column 256 or higher (256+). You would please
> more than 99.99% of users :-)

We have lines with over 400 columns at work. Yes I know, horrible.

-- 
/Jacob Carlborg

On Sep 21, 2013, at 10:22 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/21/2013 8:54 PM, Michel Fortin wrote:
>> I don't think it should be a priority, but rejecting the idea outright is shortsighted in my opinion.
> 
> I'm not rejecting the idea outright. I've actually implemented this in the dmc compiler. It's just not terribly useful, and it has costs.

I'd consider it in a similar class as the dictionary lookup that occurs when an unknown symbol is encountered.  Totally unnecessary, but it's a nice time-saver.  Is it clang that displays the line in error with a carat underneath the error?  Though if there really isn't an efficient way to do it in DMD then I don't think it's worthwhile.  I was only thinking of the parser when I mentioned the beginning-of-line pointer.  I hadn't considered the AST.