On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:
> On 9/21/2013 5:11 PM, Sean Kelly wrote:
>>> Tracking the column number is certainly doable, but it comes at a cost of
>>> memory consumption and some compile speed, since it has to be tracked in
>>> every token. I used to do it in the Digital Mars C compiler, but it was of
>>> only marginal utility and I dropped it.
>>
>> Can't you just hold a pointer to the beginning of the line and subtract to
>> find the column?  I agree that it's generally of marginal utility though.
>
> Holding the pointer has a cost of memory consumption and compile speed :-) as well as having to have the source file buffer stay around throughout the compile (to compute column number you need the source in order to account for tabs & Unicode).
>
> Of course, we can cheat and use a byte to store the column number, as after all, nobody has more than 256 columns.
>
> Then you get a bug report where someone does. So raise it to an unsigned short, then, sigh, you get another bug report where someone's entire source file is on one line, and on it goes.

I'll go for a byte, and a well written ">256" in the message when necessary... a very good compromise I'll tell!

/P

On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
> On 9/21/2013 9:34 PM, deadalnix wrote:
>> Most issue are being worked on. That being said, changing semantic in a
>> programming language is always a difficult matter, as people code relying on the
>> old bugguy behavior may break.
>
> And often the same people who want semantic changes are the ones who complain when new features break things :-(

That is expected, logical and described to you several times :P

On 09/22/2013 02:33 AM, Walter Bright wrote:
> On 9/21/2013 5:11 PM, Sean Kelly wrote:
>>> Tracking the column number is certainly doable, but it comes at a
>>> cost of
>>> memory consumption and some compile speed, since it has to be tracked in
>>> every token. I used to do it in the Digital Mars C compiler, but it
>>> was of
>>> only marginal utility and I dropped it.
>>
>> Can't you just hold a pointer to the beginning of the line and
>> subtract to
>> find the column?  I agree that it's generally of marginal utility though.
>
> Holding the pointer has a cost of memory consumption and compile speed
> :-)

(The current scheme is not optimal either.)

struct Loc
{
    const char *filename; // <--
    unsigned linnum;

Replace this pointer by a pointer or (global) offset to the first character in the source file buffer corresponding to the AST node. The file name can be recovered from this using an appropriate data structure.

In order to find the first column index, decode backwards until you hit a newline character or the beginning of the source file.

In order to find the last column index if that is wanted, re-invoke the parser. (Personally, I just store a slice into the source buffer.)

This allows the compiler to underline the location where an error occurred:

tt.d:7:14: error: need 'this' to access field 'S.member'
    auto x = S.member;
             ^~~~~~~~
tt.d:3:5: note: field was declared here
    int member;
    ^~~~~~~~~~~

Editors understand this format and can quickly jump to the location.

You could also get rid of linnum by splitting the source file buffer into lines on demand and using binary search.

> as well as having to have the source file buffer stay around
> throughout the compile  ...

Which, as far as I understand, DMD does anyway? If you do not want to keep it around, release it and reload it on demand if an error actually occurs in that buffer. (Time taken to spit out an error message does not need to be optimized that much.)

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.

On 9/21/13 11:42 PM, deadalnix wrote:
> On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:
>> On 9/21/2013 9:34 PM, deadalnix wrote:
>>> Most issue are being worked on. That being said, changing semantic in a
>>> programming language is always a difficult matter, as people code
>>> relying on the
>>> old bugguy behavior may break.
>>
>> And often the same people who want semantic changes are the ones who
>> complain when new features break things :-(
>
> Guilty here :D

We all are.

Andrei

On 9/22/13 1:12 AM, Paolo Invernizzi wrote:
> On Saturday, 21 September 2013 at 22:08:23 UTC, Andrej Mitrovic wrote:
>> On 9/21/13, Maxim Fomin <maxim@maxim-fomin.ru> wrote:
>>> (like AAs, scope, shared) are at risk to be seriously changed which is a
>>> serious problem to the user.
>>
>> These are already a serious problem to the user when they're broken
>> and under-implemented.
>
> I'm really hoping for an improvement of shared and the concurrency field.
> It's a pity having someone that having read the concurrency chapter of
> TDPL (for free, also!) start toying with shared and... "hey, it does not
> works that way? where's the "actual" documentation then? what is the
> timeline? what? no timeline? gheeez" (really happened, BTY)
>
> /Paolo

Probably this should be the next focal area.

Andrei

On Sunday, 22 September 2013 at 12:24:03 UTC, Timon Gehr wrote:
> You could also get rid of linnum by splitting the source file buffer into lines on demand and using binary search.

Does that work with #line?

On 09/22/2013 12:36 AM, Walter Bright wrote:
> On 9/21/2013 3:11 PM, Maxim Fomin wrote:
>> On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:
>>> On 9/21/2013 2:40 PM, Maxim Fomin wrote:
>>>> Thanks, that is clear. Unfortunately, I cannot say that the
>>>> explanation improves
>>>> my attidute to the language - dmd still breaks too often code and some
>>>> significant features (like AAs, scope, shared) are at risk to be
>>>> seriously
>>>> changed which is a serious problem to the user.
>>>
>>> I'm curious - was there a logic bug in your code with the overflow,
>>> or had
>>> that been the intended behavior?
>>
>> This was bug in gtkd sources when I tried to compile its most recent
>> version
>> (tried even from github) with git-head dmd. I think it is a problem of
>> gtkd
>> developers rather than dmd.
>
> Ok, so it found a latent bug in the source code - I don't think that's a
> good example of dmd being unstable - it was a good change.

I've reduced the code causing the error to this:
```
public enum GTokenType
{
	NONE,
}

public enum GtkRcTokenType
{
	INVALID = GTokenType.NONE,
	INCLUDE,
}
```

In this case the value of INVALID + 1 isn't large enough the overflow an int.

In the actual code:
https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310
Setting NONE to a value lower than 87 makes it so the code compiles without error, which only makes things weirder.

-- 
Mike Wey

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

On Sunday, 22 September 2013 at 17:15:15 UTC, Mike Wey wrote:
> I've reduced the code causing the error to this:
> ```
> public enum GTokenType
> {
> 	NONE,
> }
>
> public enum GtkRcTokenType
> {
> 	INVALID = GTokenType.NONE,
> 	INCLUDE,
> }
> ```
>
> In this case the value of INVALID + 1 isn't large enough the overflow an int.
>
> In the actual code:
> https://github.com/gtkd-developers/GtkD/blob/master/src/gtkc/glibtypes.d#L1310
> Setting NONE to a value lower than 87 makes it so the code compiles without error, which only makes things weirder.

Thanks, that's helpful.