October 26, 2010
On 2010-10-25 22:25:42 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> This is odd. I'd find if difficult to picture that. So the compiler puts the cursor exactly where it _thinks_ the error occurred. More often than not that's not even the locus of the actual error, and even if it were, I'd find it a stretch to say that that would improve my responsiveness.

It's not always at the right place, but for mistyped or just renamed function/variables it can't really miss the error location. Also, when you miss a semicolon, a closing parenthesis, a bracket, or a brace, Clang points you at the end of the previous token, this helps put the caret at the right place.

Perhaps I've just been doing too much refactoring lately. I hadn't realized this was a small time-saver until I reverted to GCC to check a few things and noticed it slowed me down. It's just a small annoyance, but it's enough to convince me to use Clang over GCC when I can.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

October 26, 2010
bearophile wrote:
>> "acts very badly" kinda means the same thing :-)
> 
> DMD acts very badly regarding that specific situation,

As I said, the two error messages it gives are right on target.
October 26, 2010
bearophile wrote:
> The C# compiler too show those column number. But last time Walter has
> explained that to do this, the compiler has to keep more data (all those line
> numbers), so this may slow down the compilation a little. And of course
> currently this information is not present, so it probably requires a good
> amount of changes to be implemented. The slowdown problem may be solved as in
> GCC, adding a compilation switch that gives/removes the column number (it
> uses to be switched off on default, now after the competition by Clang it's
> switched on on default).

Switching it off will have no effect on compile speed.

October 26, 2010
Rainer Deyke wrote:
> On 10/25/2010 19:01, Walter Bright wrote:
>> Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
>> and NOBODY CARES.
>> Not one person in 25 years has ever even commented on it. Nobody
>> commented on its lack in dmd.
> 
> I think someone just did.

Only because clang made a marketing issue out of it. Nobody coming from dmc++ noticed.

I used to point out this feature in dmc++ to users. Nobody cared, I'd just get blank looks. Why would I drop it if people wanted it?

Clang did have a nice idea with the spelling corrector. I implemented it in dmc and dmd, and got flak for "wasting time" by adding it. I still like it, though, and think it's an improvement :-)
October 26, 2010
Andrei Alexandrescu Wrote:

> This is odd. I'd find if difficult to picture that. So the compiler puts the cursor exactly where it _thinks_ the error occurred. More often than not that's not even the locus of the actual error, and even if it were, I'd find it a stretch to say that that would improve my responsiveness.

Cryptic programming FTW!
October 26, 2010
On 2010-10-26 04:25, Andrei Alexandrescu wrote:
> On 10/25/10 21:12 CDT, Michel Fortin wrote:
>> On 2010-10-25 21:01:49 -0400, Walter Bright <newshound2@digitalmars.com>
>> said:
>>
>>> bearophile wrote:
>>>> Another diagnostic feature is to not just use the caret (we have
>>>> discussed about it time ago) but it also underlines the wrong part:
>>>>
>>>> t.c:7:39: error: invalid operands to binary expression ('int' and
>>>> 'struct A')
>>>> return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
>>>> ~~~~~~~~~~~~~~ ^ ~~~~~
>>>
>>> Yes, we discussed it before. The Digital Mars C/C++ compiler does
>>> this, and NOBODY CARES.
>>> Not one person in 25 years has ever even commented on it. Nobody
>>> commented on its lack in dmd.
>>> It's a waste of time to implement things nobody cares about.
>>
>> With the above error message, when you go to the next error within
>> Xcode, it puts the text insertion caret right where the error caret is.
>> I've found in the last few months using Clang that this behaviour of
>> Xcode saves me from hitting a lot the arrow keys when correcting errors
>> because I'm already closer to where the error happened. That's even more
>> true when the same error is repeated multiple times and I can machinery
>> repeat the same fix. I actually miss the feature when I compile
>> something with GCC using Xcode, because GCC provides only the line
>> number and all Xcode can do is select the line.
>>
>> It's true that by itself, on the command line, this feature isn't
>> terribly useful. But for better integration with Xcode (or any IDE for
>> that matter), I'd like it very much if dmd printed the column number for
>> the caret in addition to the line. It's not a very important feature,
>> but just a "nice touch" that makes things a little better.
>
> This is odd. I'd find if difficult to picture that. So the compiler puts
> the cursor exactly where it _thinks_ the error occurred. More often than
> not that's not even the locus of the actual error, and even if it were,
> I'd find it a stretch to say that that would improve my responsiveness.
>
> Andrei

That is what the whole thread is about, giving better and more accurate error messages. A great example, as bearophile shows, is the missing semicolon error which Clang points to the "right" line wheres DMD, GCC points to the start of the next statement. As Walter points out this is syntactical correct since there is no correct position for the semicolon in a whitespace indepdent language but I still think bearophile is correct in this case.

-- 
/Jacob Carlborg
October 26, 2010
"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:ia5e1v$22jf$1@digitalmars.com...
> On 2010-10-25 21:57:54 -0400, Walter Bright <newshound2@digitalmars.com> said:
>
>> bearophile wrote:
>>> Walter:
>>>
>>>> It's the very next token. There's nothing wrong with the message.
>>>
>>> In that case I prefer the error message to refer to the line where the
>>> semicolon is absent. I may ask a poll to other D users to see if they
>>> agree
>>> with me or not on this.
>>
>> It's of very questionable value when you consider that D is not a line oriented language at all. There is no correct placement of ; in a sequence of whitespace.
>
> It's much faster to fix a problem when the IDE sends you right where you need to type.

One of my favourite features of the Delphi IDE was that when you compiled it would take you to the exact palce of the first error it found. And because the compile times were so fast you could just press or click compile, fix the typo / bug, press / click it again. So you could use the compile button as a "next bug to fix" button, and work your way through them very quickly.



October 26, 2010
On 26.10.2010 7:42, Walter Bright wrote:
> Rainer Deyke wrote:
>> On 10/25/2010 19:01, Walter Bright wrote:
>>> Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
>>> and NOBODY CARES.
>>> Not one person in 25 years has ever even commented on it. Nobody
>>> commented on its lack in dmd.
>>
>> I think someone just did.
>
> Only because clang made a marketing issue out of it. Nobody coming from dmc++ noticed.
>
> I used to point out this feature in dmc++ to users. Nobody cared, I'd just get blank looks. Why would I drop it if people wanted it?
>
> Clang did have a nice idea with the spelling corrector. I implemented it in dmc and dmd, and got flak for "wasting time" by adding it. I still like it, though, and think it's an improvement :-)
I actually like this  spell-checking thing. It was of great help to me, especially while I was just learning D, all those new funny function names...
Back then I thought that a mistype was the error #1 :-)

-- 
Dmitry Olshansky

October 26, 2010
Walter:

> Only because clang made a marketing issue out of it. Nobody coming from dmc++ noticed.
> 
> I used to point out this feature in dmc++ to users. Nobody cared, I'd just get blank looks. Why would I drop it if people wanted it?

Maybe it's all just marketing. But sometimes marketing is also a form of education, it teaches people a new way to do something, or why they should care about something.

Another possibity is that maybe the ecosystem around a language is changed, today more people use an IDE (especially people that don't use C/C++), and if you are using an IDE then maybe it is an useful feature.

Probably reality is a mix of those different possibilities.


> Clang did have a nice idea with the spelling corrector. I implemented it in dmc and dmd, and got flak for "wasting time" by adding it. I still like it, though, and think it's an improvement :-)

In my opinion too it's an improvement. I presume some people have said it was a "waste of time" because currently there are more important issues/bugs in DMD.


In the meantime I have underlined a second small idea from Clang that I think will be useful to implement in D/DMD too, the use of "aka", this is an example from Clang:

t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a
structure or union


This is a wrong D2 program:


void main() {
    alias int Foo;
    Foo f;
    f = f.x;
}


DMD 2.049 prints:
test.d(4): Error: no property 'x' for type 'int'

But a more useful error message may be:
test.d(4): Error: no property 'x' for type 'Foo' (aka 'int')

In a tiny program like that the difference doesn't show much, but as programs get bigger, and alias is more far from its usage, it will be useful.

The enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=5004

Bye,
bearophile
October 26, 2010
Walter Bright wrote:

> bearophile wrote:
>>> "acts very badly" kinda means the same thing :-)
>> 
>> DMD acts very badly regarding that specific situation,
> 
> As I said, the two error messages it gives are right on target.

They are and technically more so than what clang claims. The difference however is that dmd reports the error, while clang directs your attention to where you should proceed fixing the code. For trivial errors that does help, much like the spelling checker in dmd.

These days I don't even notice it anymore that, whenever I encounter this error message, I mentally parse it as 'I missed something before line 5 now where is it...'

From the programmer p.o.v. the problem this message reports is almost always located in in the very last word of the dmd message even if technically it is not:

test.d(5): found '}' when expecting ';' following statement
                                                    ^ you want to know this

Improving template related error messages however may give more bang for buck, dmd has already improved greatly in this respect and it really helps.