www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD warnings

reply Frank Benoit <frank nix.de> writes:
DMD makes warnings for sometimes serious errors.
The user can compile with -w to get the warnings.
For any bigger program it should be a good idea to switch this on.

But D is specially for "People who compile with maximum warning levels
turned on and who instruct the compiler to treat warnings as errors."
(see http://www.digitalmars.com/d/overview.html "who is D for").
Including third party code can be anoying if this code is not warning
free. e.g. phobos, mango, ares, ...

I say: lets remove the -w switch and treat all warnings as errors. No
more nice to have warnings! Instead the user has to write the program
allways error/warning free. If one specific warning can't be removed,
the user has to tell the compiler with:

pragma( nowarn, 234 ){
	// code generating the warning 234
}

So it is documented in the code. This is nice.

Perhaps it makes sense to define a standard set of warnings in the
d-specification and have literals for them:

pragma( nowarn, NoReturnAtEndOfFunction ){
	int f(){
		generateError( "throw the funky exception" );
	}
}

The compiler implementation can add his own warnings, additional to the
d-spec. The user can switch them off globally by cmdline switch. So
existing code can allways compile.

In MISRA, a coding standard for implementing C/C++ in automotive
industry, the user has a big set of rules. He should write the code,
according to the rules. If it is not possible to implement something
without breaking a rule, this is OK, but the programmer has to document
it with the cause, why he is breaking the rule. In D, this can be aided
by the compiler with such a this mechanism.

pragma( nowarn, identifier, "cause" ){
}


Frank Benoit => keinfarbton
Mar 11 2006
next sibling parent reply nick <nick.atamas gmail.com> writes:
Frank Benoit wrote:

 I say: lets remove the -w switch and treat all warnings as errors.


Seconded.
Mar 13 2006
parent Frank Benoit <frank nix.de> writes:
nick schrieb:

 Frank Benoit wrote:

 I say: lets remove the -w switch and treat all warnings as errors.


 
 Seconded.


Thanks
Mar 14 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Frank Benoit wrote:

 DMD makes warnings for sometimes serious errors.
 The user can compile with -w to get the warnings.
 For any bigger program it should be a good idea to switch this on.
 
 But D is specially for "People who compile with maximum warning levels
 turned on and who instruct the compiler to treat warnings as errors."
 (see http://www.digitalmars.com/d/overview.html "who is D for").
 Including third party code can be anoying if this code is not warning
 free. e.g. phobos, mango, ares, ...
 
 I say: lets remove the -w switch and treat all warnings as errors. No
 more nice to have warnings! Instead the user has to write the program
 allways error/warning free. If one specific warning can't be removed,
 the user has to tell the compiler with:


The problem is, those warnings are things that Walter thinks should not 
be errors. More precisely, they are code constructs that are OK, 90% of 
the time (at least, that's the case for narrowing conversions). We need
to more precisely capture the bad 10%, so that they can be turned into 
errors. Here's a few things that could be done:

* The warning about "length" can become an error, now that we have "$".
* No return value really should be an error, except when the function 
includes some inline asm. We need some way of stating that the end of 
the function is never reached, perhaps with something like "assert return":

void f(){
   for (; ;) {
     if (somevolatilefunc()) return;
     sleep();
   }
   assert return;
}

Leaving off the return statement is an error I make all the time, it 
really should not be a warning.

* Maybe something for the default in switch statements, too.
* Narrowing conversions are a big problem. I can't see how it could be 
solved, other than by introducing a narrowcast() operator (which could 
possibly throw an exception if the condition is violated).


 pragma( nowarn, 234 ){
 	// code generating the warning 234
 }
 
 So it is documented in the code. This is nice.


But it looks horrible, and it's only purpose is to turn off the warning.
Warnings are indications of problems in the language semantics -- it 
means the compiler doesn't have enough information to determine if the 
construct is erroneous or not. The solution is definitely not to make 
the construct always an error.
It would definitely be good to eliminate warnings. I know Walter hates them.
Mar 13 2006
parent reply Frank Benoit <frank nix.de> writes:
Don Clugston schrieb:

 The problem is, those warnings are things that Walter thinks should not
 be errors. More precisely, they are code constructs that are OK, 90% of
 the time (at least, that's the case for narrowing conversions). We need
 to more precisely capture the bad 10%, so that they can be turned into
 errors. Here's a few things that could be done:
 



 * The warning about "length" can become an error, now that we have "$".
 * No return value really should be an error, except when the function
 includes some inline asm. ...
 * Maybe something for the default in switch statements, too.
 * Narrowing conversions are a big problem. 


The only way to capture the bad 10% is to fix all. Thats my point,
nobody should ignore warnings, because this bad 10%.

So lets force them to be errors with a back door for emergency.


 pragma( nowarn, 234 ){
     // code generating the warning 234
 }

 So it is documented in the code. This is nice.


 But it looks horrible, and it's only purpose is to turn off the warning.


Yes it looks horrible and it shows a horrible situation. It was not
possible to fix a warning.
This should be used rarely. Instead fix warnings:
Missing cast => add one
Missing return => add a return, assert(false) or throw
...

int i =3;
uint s = cast(uint)i;

I really think it is better style to have this explicite cast in the
code. Because a reader can see, it is not only an assignment, there is
also a cast which can have side effects.

If you ignore warnings you will not be aware of this, if you read this
code in half a year.

But perhaps there is a situation you cannot fix the warning or don't
want to change the code in this way. So you have this back door.


 Warnings are indications of problems in the language semantics -- it
 means the compiler doesn't have enough information to determine if the
 construct is erroneous or not. The solution is definitely not to make
 the construct always an error.


Sure! It is easy to provide the information to the compiler. Add the
cast, return, ...
This process is valueable because you notice an error, decide to fix the
warning or decide to switch this warning off for the certain sequence.

So treating warnings as errors, forces the user to think about. And that
is the sense of warnings.

Frank
Mar 14 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Frank Benoit wrote:

 Don Clugston schrieb:

 The problem is, those warnings are things that Walter thinks should not
 be errors. More precisely, they are code constructs that are OK, 90% of
 the time (at least, that's the case for narrowing conversions). We need
 to more precisely capture the bad 10%, so that they can be turned into
 errors. Here's a few things that could be done:


 

 * The warning about "length" can become an error, now that we have "$".
 * No return value really should be an error, except when the function
 includes some inline asm. ...
 * Maybe something for the default in switch statements, too.
 * Narrowing conversions are a big problem. 


 
 The only way to capture the bad 10% is to fix all. Thats my point,
 nobody should ignore warnings, because this bad 10%.


The ideal compiler would generate error messages for everything that's a 
bug, and not for anything else. Warnings (or errors) are only useful if 
they indicate that that line of code is significantly more likely (say 
100 times) to contain a bug, than any line which does not generate any 
warnings.

Example: a missing return statement definitely falls into this category. 
But in my experience, I don't think I have ever seen a single 
signed/unsigned mismatch that was a bug -- but I've seen that warning in 
C++ thousands upon thousands of times.


 So lets force them to be errors with a back door for emergency.
 

 pragma( nowarn, 234 ){
     // code generating the warning 234
 }

 So it is documented in the code. This is nice.


 But it looks horrible, and it's only purpose is to turn off the warning.


 
 Yes it looks horrible and it shows a horrible situation. It was not
 possible to fix a warning.
 This should be used rarely. Instead fix warnings:
 Missing cast => add one
 Missing return => add a return, assert(false) or throw
 ...
 
 int i =3;
 uint s = cast(uint)i;
 
 I really think it is better style to have this explicite cast in the
 code. Because a reader can see, it is not only an assignment, there is
 also a cast which can have side effects.


The problem is, that is *not* what a cast says! Suppose you change the 
definition of i to be:
double i = sin(56);
Now, the line about s will compile without warnings. Adding the cast has 
  removed the warning, but it has also cluttered the code and introduced 
a latent bug. You also won't be able to use a lint tool (or even -w) to 
find the problem. Casts are evil. Thousands of time more evil than 
changing from signed to unsigned.


 If you ignore warnings you will not be aware of this, if you read this
 code in half a year.
 
 But perhaps there is a situation you cannot fix the warning or don't
 want to change the code in this way. So you have this back door.
 

 Warnings are indications of problems in the language semantics -- it
 means the compiler doesn't have enough information to determine if the
 construct is erroneous or not. The solution is definitely not to make
 the construct always an error.


 
 Sure! It is easy to provide the information to the compiler. Add the
 cast, return, ...
 This process is valueable because you notice an error, decide to fix the
 warning or decide to switch this warning off for the certain sequence.
 
 So treating warnings as errors, forces the user to think about. And that
 is the sense of warnings.


Yes, but *only* if the warning is removed in a way that results in less 
ambiguous, less buggy code. Right now, we don't have language mechanisms 
that do that for all the cases that currently produce warnings. 
Hopefully they will come eventually.
Mar 14 2006
parent Frank Benoit <frank nix.de> writes:
Don Clugston schrieb:

 Example: a missing return statement definitely falls into this category.
 But in my experience, I don't think I have ever seen a single
 signed/unsigned mismatch that was a bug -- but I've seen that warning in
 C++ thousands upon thousands of times.
 


Good point. "Missing casts" are really the mass of the warnings. And
adding hundreds of casts will make blind situations you described.
I think to bring in better cast statements, to give the compiler more
information.
Something like
sign(), unsign(): e.g. long->ulong, uint->int
shrink()        : e.g. int->short, ulong->ubyte, double->float
If the compiler knows better about the users intention, he could warn
better.

Frank
Mar 14 2006