"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g530j8$18th$1@digitalmars.com...
> The reason for treating warnings as errors when warnings are enabled is so that, for a long build, they don't scroll up and off your screen and go unnoticed.

Pardon me for saying so, but that doesn't sound like a very convincing reason to turn every warning (which, by it's very nature, is something that might not be a bug) into something that splits the language into what are effectively different languages.

In all the time I've spent using Microsoft compilers, I've found the "x number of errors, y number of warnings" display at the end of every compile to be perfectly sufficient for the problem you point out. If a build involves many different calls to a compiler, then whatever rebuild-like tool is being used could be made to screen-scrape and total up the warnings and errors. Or the compiler could stick the error/warning counts along in an output file that gets read and accumulated by the rebuild/make tool. Or a copy of all the output could just be piped into a "grep for the error/warning counts" tool. This way, DMD's warnings could be lint-like warnings instead of the language-splitting "optional errors" (which I can understand your reluctance to create more of) that they are now. A "treat warnings as errors" flag could be retained for any large builds that involve multiple compiler invokations but for some reason still don't do any form of proper cumulative "x warnings / x errors".

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g530ol$18th$2@digitalmars.com...
> Nick Sabalausky wrote:
>> Warings are never sure hints about a bug in the program either. That's what makes them warnings.
>
> Not always. Sometimes they are the result of an inability to change the language specification (because it's a standard). Common C++ compiler warnings are indications of bugs in the standard that can't be fixed.

Fair enough. But that doesn't really apply to the current state of D, though, does it?

"BCS" <ao@pathlink.com> wrote in message news:55391cb32ef798caafd0fdb12c62@news.digitalmars.com...

> At some point the issue arises of "is this what the end user wants?" (lint can't help you there :)

I would love to have a "deal with the client" tool I could delegate all of that stuff to ;)

Reply to Steven,

> "Walter Bright" wrote
> 
>> The reason for treating warnings as errors when warnings are enabled
>> is so that, for a long build, they don't scroll up and off your
>> screen and go unnoticed.
>> 
> I've been following this thread, and I'm not really sure which side of
> the issue I'm on, but this, sir, is one of the worst explanations for
> a feature. Ever heard of 'less'?  or 'more' on Windows?  Maybe piping
> to a file?  Maybe using an IDE that stores all the warnings/errors for
> you?
> 
> Please stop saving poor Mr. ignorant programmer from himself.
> Education is the key to solving this problem, not catering to the
> ignorance.
> 
> Sorry for the harshness, but seriously!
> 
> -Steve
> 

I think grep is more useful there. I have a few builds that have several pages of output on a successful build and I sometimes miss even the errors.

(I once had an error that didn't even fit in the scroll back buffer, but that was just a bit nuts ;)

Nick Sabalausky wrote:
> Fair enough. But that doesn't really apply to the current state of D, though, does it? 

No, except for 1.0.

Many common C++ warnings were put into D as errors because the spec could be changed.

BCS Wrote:
[...]
> 
> I think grep is more useful there. I have a few builds that have several pages of output on a successful build and I sometimes miss even the errors.
> 
> (I once had an error that didn't even fit in the scroll back buffer, but that was just a bit nuts ;)

That's why I think having a "tee" is even better :-)
Anyway, you cannot do anything useful under Windows unless
it is in a Cygwin bash...
Ciao
Tom

Reply to tomD,

> BCS Wrote:
> [...]
>> I think grep is more useful there. I have a few builds that have
>> several pages of output on a successful build and I sometimes miss
>> even the errors.
>> 
>> (I once had an error that didn't even fit in the scroll back buffer,
>> but that was just a bit nuts ;)
>> 
> That's why I think having a "tee" is even better :-)
> Anyway, you cannot do anything useful under Windows unless
> it is in a Cygwin bash...

<sarcastic>No? You can't?!</sarcastic> <G/>

Your right and Oooh do i feel it now and again.

BCS wrote:
> Reply to tomD,
> 
>> BCS Wrote:
>> [...]
>>> I think grep is more useful there. I have a few builds that have
>>> several pages of output on a successful build and I sometimes miss
>>> even the errors.
>>>
>>> (I once had an error that didn't even fit in the scroll back buffer,
>>> but that was just a bit nuts ;)
>>>
>> That's why I think having a "tee" is even better :-)
>> Anyway, you cannot do anything useful under Windows unless
>> it is in a Cygwin bash...
> 
> <sarcastic>No? You can't?!</sarcastic> <G/>
> 
> Your right and Oooh do i feel it now and again.
> 
> 

I agree Cygwin is nice, but go get yourself the gnuwin32 tools.  Then you'll be able to use all your favorite unix commands (like 'tee') from the dos box.  Makes it much less painful.  And get Console2 also.

--bb

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g530j8$18th$1@digitalmars.com...
>> The reason for treating warnings as errors when warnings are enabled is so that, for a long build, they don't scroll up and off your screen and go unnoticed.
> 
> Pardon me for saying so, but that doesn't sound like a very convincing reason to turn every warning (which, by it's very nature, is something that might not be a bug) into something that splits the language into what are effectively different languages.

I'll draw on my 25 years of experience with warnings to answer this.

If you turn warnings on, then you want to see them and presumably deal with them. If you don't deal with them, then they persist every time you compile, and either they get very irritating and you fix them anyway, or you develop a blind spot for them and never see the ones you do want to fix.

Piping the output into a file and then perusing it manually looking for warning statements is never going to happen. Complex builds tend to produce a lot of output, and poking through it looking for warnings every time you build is not practical. Changing your build process to point out warnings is the same thing as the compiler treating them as errors, except it's extra work for the build master.

Trying to educate your programmers into doing extra work to deal with warnings that scroll off the screen is a lost cause.

If you're using a static analysis tool, such as Coverity, which produces lots of spurious warnings, it is not put in the build process. It's run occasionally as a separate evaluation tool.

Steven Schveighoffer Wrote:

> "Walter Bright" wrote
> > The reason for treating warnings as errors when warnings are enabled is so that, for a long build, they don't scroll up and off your screen and go unnoticed.
> 
> I've been following this thread, and I'm not really sure which side of the issue I'm on, but this, sir, is one of the worst explanations for a feature. Ever heard of 'less'?  or 'more' on Windows?  Maybe piping to a file?  Maybe using an IDE that stores all the warnings/errors for you?
> 
> Please stop saving poor Mr. ignorant programmer from himself.  Education is the key to solving this problem, not catering to the ignorance.
> 
> Sorry for the harshness, but seriously!

in c++ this kind of argument that contains "it's an issue of education and shit" in it has been used for many years. after a lot of experience in the field nowadays everyone silently agrees that that argument is useless. folks on comp.lang.c++ start mocking you if u bring that argument up.

i am 110% on walter's side on this shit. there should be no warnings and shit. only errors. it is not catering to the ignorant. it is a matter of a properly defined language.

a lint tool should not be folded into d. such a tool could e.g. follow pointers, do virtual execution, and some other weird shit. it could run for hours and produce output that takes an expert to interpret. that kind of shit does not belong in the compiler.