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

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.

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

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.

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

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/

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

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/

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

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