www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More Clang diagnostic

reply bearophile <bearophileHUGS lycos.com> writes:
LLVM devs keep adding new nice things to Clang diagnostic, so here I am again
to show them:
http://clang.llvm.org/diagnostics.html


The first nice diagnostic feature is the usage of "aka":

  t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a
structure or union
    myvar = myvar.x;
            ~~~~~ ^

Some time ago I have added an enhancement request on this:
http://d.puremagic.com/issues/show_bug.cgi?id=5004

For me there's no doubt this is a nice little diagnostic feature to have in D
too, is it doable in D/DMD?

--------------------

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);
                         ~~~~~~~~~~~~~~ ^ ~~~~~

--------------------

"Fix-it Hints" are a diagnostic feature that I think is generally missing in D,
it is related to the compiler hints I have discussed about time ago. It says
how to fix localized problems (the next step for compilers is to fix the source
code themselves :-) ):


  $ clang t.c
  t.c:5:28: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                          ~~ ^
                          .x = 
  t.c:5:36: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                                  ~~ ^
                                  .y = 


  $ clang t.c
  t.c:4:8: error: expected ';' after expression
    bar()
         ^
         ;

--------------------

Regarding the section titled "Quality of Implementation and Attention to Detail"

This is the Clang error:


t.c:5: error: expected ';' before '}' token
$ clang t.c
t.c:4:8: error: expected ';' after expression
  bar()
       ^
       ;


And this may be an equivalent D program (the C code that generates the error
isn's shown):


void foo() {}

void main() {
    foo()
}


DMD 2.049 shows a worse error message:

test.d(5): found '}' when expecting ';' following statement
test.d(5): found 'EOF' when expecting '}' following compound statement

I'd like the missing ; error to refer to where it's actually missing, in D code.


Recently I have added a bug report that may be related:
http://d.puremagic.com/issues/show_bug.cgi?id=5114

----------------------------

The last example from that page, the error message shown by Clang:


$ gcc-4.2 t.c
t.c:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
$ clang t.c
t.c:3:1: error: unknown type name 'foo_t'
foo_t *P = 0;
^


A possible D version of the invisible C code:


void main() {
    foo_t *P = null;
}


Unfortunately here DMD 2.049 acts very badly:

test.d(2): Error: identifier 'foo_t' is not defined
test.d(2): Error: foo_t is used as a type
Assertion failure: 'tn->mod == MODimmutable' on line 879 in file 'mtype.c'


So I've just added a bug report, I don't know if it's a dupe:
http://d.puremagic.com/issues/show_bug.cgi?id=5119

Bye,
bearophile
Oct 25 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.



 --------------------
 
 "Fix-it Hints" are a diagnostic feature that I think is generally missing in D,


dmd has quite a few of them, like:

error("storage class 'auto' is invalid when declaring a class, did you mean to 
use 'scope'?");



   $ clang t.c
   t.c:4:8: error: expected ';' after expression
     bar()
          ^
          ;
 DMD 2.049 shows a worse error message:
 
 test.d(5): found '}' when expecting ';' following statement
 test.d(5): found 'EOF' when expecting '}' following compound statement
 
 I'd like the missing ; error to refer to where it's actually missing, in D
code.


It's the very next token. There's nothing wrong with the message. In fact, I 
think it is better than the clang one. The clang one is wrong as a ; terminates 
a statement, not an expression.




 void main() {
     foo_t *P = null;
 }
 
 
 Unfortunately here DMD 2.049 acts very badly:
 
 test.d(2): Error: identifier 'foo_t' is not defined
 test.d(2): Error: foo_t is used as a type
 Assertion failure: 'tn->mod == MODimmutable' on line 879 in file 'mtype.c'


The assert is a bug, but the first two messages are right on target.
Oct 25 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
I wasn't implying that DMD is bad regarding error messages, on the contrary DMD
error messages are better than the ones given by GCC on C. But there's always
space for improvements (see bug 5004) :-)

I have seen several people say good things about Clang. DMD often produces
error messages as good as Clang ones, and yet no one says equally good things
on Reddit about this good feature of D/DMD :-( I think a bit more advertisement
on this will be positive (I may write a post about this somewhere). Of course
those people have to develop C/C++ code, instead of D, so they are rightly more
interested in a good tool for C/C++.


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.

Bye,
bearophile
Oct 25 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 I wasn't implying that DMD is bad regarding error messages,


"acts very badly" kinda means the same thing :-)


 on the contrary DMD error messages are better than the ones given by GCC on
 C. But there's always space for improvements (see bug 5004) :-)
 
 I have seen several people say good things about Clang. DMD often produces
 error messages as good as Clang ones, and yet no one says equally good things
 on Reddit about this good feature of D/DMD :-( I think a bit more
 advertisement on this will be positive (I may write a post about this
 somewhere).


Back in the 80s, when magazines published benchmarks on the 30 or so C 
compilers, often the Zortech compiler was the fastest, and Borland came in 
second. Despite what the journalist's own data showed, they'd then proceed to 
write in the accompanying text that Borland's was the fastest. It was 
unbelievably frustrating.



 Of course those people have to develop C/C++ code, instead of D,
 so they are rightly more interested in a good tool for C/C++.
 
 
 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.
Oct 25 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 "acts very badly" kinda means the same thing :-)


DMD acts very badly regarding that specific situation, and on average it acts
quite better than GCC (and on average a little worse than Clang).

Have you appreciated this idea from Clang?
http://d.puremagic.com/issues/show_bug.cgi?id=5004



 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.


I think the same may be said about C/C++ code where those Clang error messages
come from. My editor goes to the line number DMD gives in its error messages,
so if DMD gives the line of the next token I often have to look back to find
the right spot. It's not an important thing, I have not filed a bug report on
this, but in this case I prefer the error message given by Clang :-)

Bye,
bearophile
Oct 25 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 25 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
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.
Oct 26 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Walter Bright wrote:

 bearophile wrote:

 "acts very badly" kinda means the same thing :-)


 DMD acts very badly regarding that specific situation,


=20
 As I said, the two error messages it gives are right on target.


	"AssertionFailure: 'tn->mod =3D=3D MODimmutable' on line 879 in file
'mtype.c'" is "right on target" when compiling a D source file?? I'd
hate to see a message you consider bad ;)

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 26 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jérôme M. Berger wrote:

 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.


 
 	"AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
 'mtype.c'" is "right on target" when compiling a D source file?? I'd
 hate to see a message you consider bad ;)


As I also said, that was a compiler bug, and I was referring to the two 
diagnostic messages preceding it.
Oct 26 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Walter Bright wrote:

 J=C3=A9r=C3=B4me M. Berger wrote:

 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.


     "AssertionFailure: 'tn->mod =3D=3D MODimmutable' on line 879 in fi=




le

 'mtype.c'" is "right on target" when compiling a D source file?? I'd
 hate to see a message you consider bad ;)


=20
 As I also said, that was a compiler bug, and I was referring to the two=



 diagnostic messages preceding it.


	Yes, but I believe that the reason bearophile said "acts very
badly" is because of the assert, since the other two messages are
more or less the same as the clang message (albeit slightly more
verbose).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 26 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Jérôme M. Berger wrote:

 Walter Bright wrote:

 Jérôme M. Berger wrote:

 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.


     "AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
 'mtype.c'" is "right on target" when compiling a D source file?? I'd
 hate to see a message you consider bad ;)


 As I also said, that was a compiler bug, and I was referring to the two
 diagnostic messages preceding it.


 
 	Yes, but I believe that the reason bearophile said "acts very
 badly" is because of the assert, since the other two messages are
 more or less the same as the clang message (albeit slightly more
 verbose).


I don't agree, as the thread is about quality of error messages, not bugs in
the 
compiler.
Oct 26 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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.

There might not be a "right" place to type that semicolon, but it's not 
hard to anticipate that 99.999% of the time (if not more) right next to 
the previous token will be the right place for missing terminators and 
separators.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 25 2010
parent "JimBob" <jim bob.com> writes:
"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.
Oct 26 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 25 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:


 I'd like it very much if dmd printed the column number 
 for the caret in addition to the line.



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).

Bye,
bearophile
Oct 25 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:


 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.
Oct 25 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 26/10/2010 04:32, Walter Bright wrote:

 bearophile wrote:


 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.


Why is that? What would cause a loss in compile speed even if this 
option was turned off?

-- 
Bruno Medeiros - Software Engineer
Nov 24 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:

 Why is that? What would cause a loss in compile speed even if this 
 option was turned off?


Maybe because the data structures used to keep the data around are used and
kept even when you disable that feature (the switch just disables the printing).

Bye,
bearophile
Nov 24 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/11/2010 17:33, bearophile wrote:

 Bruno Medeiros:

 Why is that? What would cause a loss in compile speed even if this
 option was turned off?


 Maybe because the data structures used to keep the data around are used and
kept even when you disable that feature (the switch just disables the printing).

 Bye,
 bearophile


So was Walter talking about GCC specifically, not the feature in 
general, theoretical terms (ie, as applied to any compiler)?

-- 
Bruno Medeiros - Software Engineer
Nov 24 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:


 So was Walter talking about GCC specifically, not the feature in 
 general, theoretical terms (ie, as applied to any compiler)?


I think he was talking about the version of DMC present at that time.

It is possible to disable a field in a data structure, but you may need to
double the code (template it), or put that datum at the end of the node structs
and not allocate&use it according to a runtime switch, etc.

Bye,
bearophile
Nov 24 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-25 22:21:01 -0400, bearophile <bearophileHUGS lycos.com> said:


 Michel Fortin:
 

 I'd like it very much if dmd printed the column number
 for the caret in addition to the line.


 

 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.


It's not that hard to implement. I did a custom version of the DMD 
frontend to do something similar for the early versions of D for Xcode. 
I needed to have the exact start and end location of each token 
expressed in character index from the beginning of the file. I used 
that for syntax highlighting.

To get column numbers in error messages, here's all I'd expect you need to do:

1. add a column field to the Loc struct (in mars.h)
2. make the lexer keep track of the current column
3. make error() print that field

Give it a try if you want.

Then you can do some benchmark to check how slower it is (probably 
nothing noticeable).

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 27 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 25 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Oct 25 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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!
Oct 25 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Oct 26 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Jacob Carlborg wrote:

 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 semicolo=


n

 in a whitespace indepdent language but I still think bearophile is
 correct in this case.
=20


	Of course, with C it is even worse since the place gcc points to
may not even be in the right *file*...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 26 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
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.


-- 
Rainer Deyke - rainerd eldwood.com
Oct 25 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Oct 25 2010
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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...


-- 
Dmitry Olshansky
Oct 26 2010
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:

 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...


I'm looking to you, Andrei!!!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y ya no tengo colores, sólo gris y negro
Aquí donde el amor es de hierro
Los días pasan y moriremos contando el tiempo
Oct 26 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/26/10 9:07 CDT, Leandro Lucarella wrote:

 Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:

 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...


 I'm looking to you, Andrei!!!


I'm ducking.

Andrei
Oct 26 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Oct 26 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:
bearophile schrieb:

 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


It's not just the aka that would be really helpful here, but especially the
"type Foo" instead of 
"type int".
Sometimes you have aliased types you use without really thinking too much about
their real type, 
like FILE, socket_t and stuff like that.
So when you get an error-message talking about int or something and your code
says socket_t it may 
be harder to find the error - especially when you have got multiple variables
of different types in 
one line.
Of course getting information about types (the "logical" type like socket_t and
the original type 
like int) in the error-message like in bearophiles "aka" suggestion would be
the best solution :)
Oct 26 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 26/10/2010 04: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?


Could this be because of some particular bias or idiosyncrasy on the 
part of dmc++ users? Any idea what the C++ user community at large would 
think of a such a feature, prior to Clang?

I'm trying to think back to days when I used VS C++ 6 and VS C++ 2003, 
but I can't remember if the error messages were just line-based, or had 
more precision than that.


As for me, I think this functionality is useful, but only significantly 
so when integrated into an IDE/editor.

-- 
Bruno Medeiros - Software Engineer
Nov 24 2010
prev sibling parent Juanjo Alvarez <nospam nospam.com> writes:
Walter Bright Wrote:


 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.


I think that is a nice feature to have in a compiler. No life-chaging, no
critical, but still nice.
Oct 28 2010