July 06, 2008
"Koroskin Denis" <2korden@gmail.com> wrote in message news:op.udu17gmcenyajd@korden...
> On Sun, 06 Jul 2008 10:45:03 +0400, Walter Bright <newshound1@digitalmars.com> wrote:
>
>> Nick Sabalausky wrote:
>>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to.
>>
>> The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
>>
>> So, why not just turn off the warnings?
>>
>> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. If you're faced with compiling someone else's code (like you downloaded it off the internet and have to compile it because it only is distributed as source) and warnings go off, is that a bug in the code or not? What do you do?
>>
>> Some shops have a "thou shall compile with warnings enabled, and there shall be no warning messages." That causes problems when you port the code to a different compiler with a different, even contradictory, notion of what is a warning. So then you wind up putting wacky things in the code just to get the compiler to shut up about the warnings.
>>
>> Those kind of things tend to interfere with the beauty of the code, and since they are not necessary to the program's logic, they tend to confuse and misdirect the maintenance programmer (why is this variable pointlessly referenced here? Why is this unreachable return statement here? Is this a bug?)
>>
>> There is a place for warnings, however. That is in a separate static analysis tool (i.e. lint, coverity, etc.) which can be armed with all kinds of heuristics with which to flag questionable constructs. I don't think they should be part of the compiler, however.
>
> Since DMD already has -w switch, why not make use of it? I think it would be a good practice to compile your code with -w on just once in a while, say, before a public release. This should enable more strick code checking, like unused methods, variables, unreachable code etc.

Not to beat a dead horse, but I always have warnings permanently turned on in every compiler I use, including DMD.


July 06, 2008
Walter Bright wrote:
> There is a place for warnings, however. That is in a separate static analysis tool (i.e. lint, coverity, etc.) which can be armed with all kinds of heuristics with which to flag questionable constructs. I don't think they should be part of the compiler, however.

The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?
July 06, 2008
Robert Fraser wrote:
> The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?

Generally for the reasons already mentioned.

Warnings are properly in the scope of static analysis tools, which have a different purpose than a compiler.
July 06, 2008
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g4pplc$gno$1@digitalmars.com...
> Nick Sabalausky wrote:
>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to.
>
> The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
>
> So, why not just turn off the warnings?
>
> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language.

I really don't see how this is, unless every compiler always has "treat warnings as errors" permanently enabled with no way to disable. That's like saying that using different lint tools, or different settings within a the same lint tool constitutes different versions of the same language, and then claiming that means we shouldn't use lint tools.

>  If you're faced with compiling someone else's code (like you downloaded
> it off the internet and have to compile it because it only is distributed
> as source) and warnings go off, is that a bug in the code or not? What do
> you do?
>

By definition, that's not an error. Even if it is a manefestation of a bug, that's no reason to deliberately be silent - bugs should be noisy. What do you do? Whatever you would normally do when you come across something in a program that you're not sure is right or not. It's not an issue that's specific (or partucularly relevant, imho) to compiler warnings.

> Some shops have a "thou shall compile with warnings enabled, and there shall be no warning messages."

That's a management problem, not a compiler design problem. (But I'm not saying that deliberately minimizing warning conditions is bad. I'm just saying that being strict enough that it becomes a problem, ie not balancing it with practical common sence, is just begging for trouble, and there's no reason we should be bending backwards to help compensate for the bad management choices of certain teams.)

> That causes problems when you port the code to a different compiler with a different, even contradictory, notion of what is a warning. So then you wind up putting wacky things in the code just to get the compiler to shut up about the warnings.
>
> Those kind of things tend to interfere with the beauty of the code, and since they are not necessary to the program's logic, they tend to confuse and misdirect the maintenance programmer (why is this variable pointlessly referenced here? Why is this unreachable return statement here? Is this a bug?)
>

Thus comments.

> There is a place for warnings, however. That is in a separate static analysis tool (i.e. lint, coverity, etc.) which can be armed with all kinds of heuristics with which to flag questionable constructs. I don't think they should be part of the compiler, however.

Like I've said, compiler warnings are essentialy a built-in lint tool. I see no reason to think of them any other way.


July 06, 2008
Walter Bright wrote:
> Robert Fraser wrote:
>> The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?
> 
> Generally for the reasons already mentioned.
> 
> Warnings are properly in the scope of static analysis tools, which have a different purpose than a compiler.

A compiler is not a documentation generator or a header generator, yet DMD does both (with some switches). Why not the same with lint-like functionality?
July 07, 2008
Walter Bright wrote:
> Nick Sabalausky wrote:
>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to. 
> 
> The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
> 
> So, why not just turn off the warnings?
> 
> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. If you're faced with compiling someone else's code (like you downloaded it off the internet and have to compile it because it only is distributed as source) and warnings go off, is that a bug in the code or not? What do you do?
> 
> Some shops have a "thou shall compile with warnings enabled, and there shall be no warning messages." That causes problems when you port the code to a different compiler with a different, even contradictory, notion of what is a warning. So then you wind up putting wacky things in the code just to get the compiler to shut up about the warnings.
> 
> Those kind of things tend to interfere with the beauty of the code, and since they are not necessary to the program's logic, they tend to confuse and misdirect the maintenance programmer (why is this variable pointlessly referenced here? Why is this unreachable return statement here? Is this a bug?)

I agree. Unfortunately, there's a problem with the 'optional' warnings we have in DMD right now. They are not optional for libraries. If a library generates warnings, then it is not usable by anyone who wants to compile with warnings enabled.

I'd love to see the warnings tightened up so that they can become bugs.

> There is a place for warnings, however. That is in a separate static analysis tool (i.e. lint, coverity, etc.) which can be armed with all kinds of heuristics with which to flag questionable constructs. I don't think they should be part of the compiler, however.
July 07, 2008
Don wrote:
> Walter Bright wrote:
>> Nick Sabalausky wrote:
>>> I don't suppose there's any chance of DMD getting a warning for variables/arguments that are declared but never accessed? Just today alone there's been two bugs I spent 10-30 minutes going nuts trying to track down that turned out to be variables I had intended to use but forgot to. 
>>
>> The problem with unused variable warnings is they are annoying when you're developing code in an iterative manner. They get in the way when you're commenting out sections of code to try and isolate a problem. They can be a problem when using "version" and "static if" statements.
>>
>> So, why not just turn off the warnings?
>>
>> The problem with warnings is that if there are n warnings, there are essentially n factorial different versions of the language. If you're faced with compiling someone else's code (like you downloaded it off the internet and have to compile it because it only is distributed as source) and warnings go off, is that a bug in the code or not? What do you do?
>>
>> Some shops have a "thou shall compile with warnings enabled, and there shall be no warning messages." That causes problems when you port the code to a different compiler with a different, even contradictory, notion of what is a warning. So then you wind up putting wacky things in the code just to get the compiler to shut up about the warnings.
>>
>> Those kind of things tend to interfere with the beauty of the code, and since they are not necessary to the program's logic, they tend to confuse and misdirect the maintenance programmer (why is this variable pointlessly referenced here? Why is this unreachable return statement here? Is this a bug?)
> 
> I agree. Unfortunately, there's a problem with the 'optional' warnings we have in DMD right now. They are not optional for libraries. If a library generates warnings, then it is not usable by anyone who wants to compile with warnings enabled.
> 
> I'd love to see the warnings tightened up so that they can become bugs.

Of course, I mean 'errors' not bugs!

> 
>> There is a place for warnings, however. That is in a separate static analysis tool (i.e. lint, coverity, etc.) which can be armed with all kinds of heuristics with which to flag questionable constructs. I don't think they should be part of the compiler, however.
July 08, 2008
Robert Fraser wrote:
> Walter Bright wrote:
>> Robert Fraser wrote:
>>> The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?
>>
>> Generally for the reasons already mentioned.
>>
>> Warnings are properly in the scope of static analysis tools, which have a different purpose than a compiler.
> 
> A compiler is not a documentation generator or a header generator, yet DMD does both (with some switches). Why not the same with lint-like functionality?

Because what constitutes a proper warning is a very subjective issue, there is plenty of room for different ideas. If it was in the compiler, it would inhibit development of static analysis tools, and would confuse the issue of what was correct D code.
July 08, 2008
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g4v646$c2j$1@digitalmars.com...
> Robert Fraser wrote:
>> Walter Bright wrote:
>>> Robert Fraser wrote:
>>>> The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?
>>>
>>> Generally for the reasons already mentioned.
>>>
>>> Warnings are properly in the scope of static analysis tools, which have a different purpose than a compiler.
>>
>> A compiler is not a documentation generator or a header generator, yet DMD does both (with some switches). Why not the same with lint-like functionality?
>
> Because what constitutes a proper warning is a very subjective issue, there is plenty of room for different ideas.

Ok, so the different warnings should be able to be turned on and off. If you don't agree with a particular type of warning then you turn it off. That's the nice thing about warnings as opposed to errors: they're optionally letting you know about certain conditions that you might want to be aware of, and they do it without changing, redefining, or otherwise affecting the language itself.

> If it was in the compiler, it would inhibit development of static analysis tools,

Can you elaborate on how this would happen?

> and would confuse the issue of what was correct D code.

Anything that generates a warning instead of an error is by definition valid code. If it wasn't valid it would generate an error instead of a warning.

Although, if by "correct" you're referring to style guidelines instead of syntactic and semantic validity, then I still disagree that it's an issue. For instance, I don't think many people would be opposed to having an optional switch that checked for consistent indentation style (I'm not actually requesting this though). People have different indentation style preferences, so the type of indentation could be configued, but perhaps have some sort of default. I can't imagine that confusing people as to what correct style was. Anyone who isn't an absolute novice is well aware of what does and doesn't constitute an issue of style (If it doesn't cause compile-time/runtime errors, then it's a matter of style).


July 08, 2008
== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Robert Fraser wrote:
> > Walter Bright wrote:
> >> Robert Fraser wrote:
> >>> The compiler already has full semantic knowledge of the code, and at least some of the warnings seem like "low-hanging fruit" so why not make the compiler act as a "mini-lint"?
> >>
> >> Generally for the reasons already mentioned.
> >>
> >> Warnings are properly in the scope of static analysis tools, which have a different purpose than a compiler.
> >
> > A compiler is not a documentation generator or a header generator, yet DMD does both (with some switches). Why not the same with lint-like functionality?
> Because what constitutes a proper warning is a very subjective issue, there is plenty of room for different ideas. If it was in the compiler, it would inhibit development of static analysis tools, and would confuse the issue of what was correct D code.

And regarding this particular issue, it's not uncommon to have unused function parameters.  And while C++ allows them to be left out:

void fn( int ) {}

D does not.  A warning for this would be terribly annoying.


Sean