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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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



"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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Walter Bright wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
 Walter Bright wrote:
 bearophile wrote:
 "acts very badly" kinda means the same thing :-)



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


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



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

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.

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

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.

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.

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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=

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

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

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

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

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