Regarding compiler switches

[Nick Sabalausky]

"div0" <div0 at users.sourceforge.net> wrote in message 
news:hd1fa2$1e20$1 at digitalmars.com...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nick Sabalausky wrote:
>>
>> Ok, great. Now take the way C/C++ is with warnings right now, as you've
>> described, then change it so that *all* C/C++ warnings are *always* 
>> treated
>> as errors, and tell me how in the world that doesn't make the situation
>> *even worse*, let alone somehow better.
>
> I've never come across a single useful C/C++ warning.
> They are all either pointless or they are errors.
>
> In my code at work all the warnings that are errors are prompted to
> errors and the rest get switched off. And that's a code base started
> over 20 years ago, hacked on by hundreds of people and moved though 4
> different compilers.
>
> None of our code emits warnings. That way you can actually spot errors
> in the compiler output instead of wading though hundreds of lines of
> irrelevant garbage.
>
>>
>> The only difference would be that if a warning gets through, instead of
>> being a mere potential annoyance to the client, you'll have broken their
>> whole damn build. Wonderful! How could that possibly be an improvement?
>>
>
> It's easy don't have the warnings in the first place.


You're missing my point. To briefly reiterate: I proposed adding an optional 
switch to let people treat warnings as errors, and you were adamant that 
shouldn't get added ("NO NO NO NO NO!"), which would indicate you consider 
it better to force all warnings to be errors than to allow users to 
optionally make them non-fatal.

I'm well aware you want a lack of warnings, but *that wasn't the question*. 
The question was, *given a situation where there ARE warnings*, particularly 
current real-world C/C++ since that's the example you used, why do you 
consider it *better* to not allow anyone to compile with warnings as 
non-fatal (as opposed to allowing people to have their warnings non-fatal if 
they want to)? Whether or not warnings should exist in the first place is 
*not part of the question*.


>
>> Besides, I've been starting to wonder if the *real* problem isn't that
>> warning settings always get propogated to libraries (instead of being
>> settable on a package-by-package basis. For instance, why shouldn't a
>> programmer be able to tell the compiler "I want these warning settings 
>> for
>> this app I'm compiling, but to hell with any potential warnings in xx and 
>> yy
>> libraries because that ain't my damn code so don't bug me with it right
>> now!"?). I'd think that would fix all those problems with warnings that
>> you've described, at least for the most part. Of course, that probably 
>> can't
>> be fixed in C++ (but then, what *can* be fixed in C++? ;) ), but D 
>> actually
>> has a module system which should make it possible, at least in theory.
>
> That's a really good idea. Any chance of a patch?
>


I'd love to give it a shot, unfortunately I already have a lot on my plate 
right now. Maybe I'll get to it sometime though :/.

But one problem is, Walter has already indicated that he's not particularly 
interested in adding new warning-related compiler switches, so unless that 
changes, there are a lot of other things I can work on that don't have a 
high likelyhood of being ignored just like my #2567 "-ww" "warnings as 
warnings" patch.


>> As far as warnings belonging in a separate lint tool...well, show me a D
>> lint tool that, at a minimum, handles the warnings DMD emits, and 
>> preferably
>> doesn't require the whole f*cking parse process to be repeated, and I'd 
>> be
>> perfectly happy having all warnings ripped out of my compiler. But there 
>> is
>> no such D lint tool, in fact, there ain't no D lint tool at all! So until
>> that actually gets made, what we have is warnings, and as I've said 
>> above,
>> having optional non-fatal warnings, bad it it might potentially be, is a
>> hell of a lot better than forcing all the warnings to be toggleable 
>> errors.
>
> What's wrong with rerunning the whole parse process?
>
> It's not as though it takes long or are you compiling on an iPhone or
> something?
>
> One of the c++ apps I work on takes 2:58 seconds just to link and a full
> build takes nearly 30 minutes, so the fraction of a second DMD takes
> isn't really an issue as far as I'm concerned.
>


First of all, just to be clear, I should point out that I really meant 
"parse+semantics and mixin expansion, etc", not just "parse" because all of 
that stuff, everything before optimization and codegen, will need to be done 
for a good lint tool.

Second thing I want to point out, to be clear, is that I would want to set 
up the lint tool to run on every build. The reason for that should be fairly 
clear, as it's the same reason people prefer compile-time errors over 
run-time errors: I want those messages because they might indicate bugs or a 
potential for bugs, and if there's potential bugs, I want it be brought to 
my attention as early as possible, such as, on the first build after they 
were introduced into the code in the first place. Doing otherwise would 
defeat much of the potential usefulness of a lint tool.

Ok, so with that out of the way, to answer your question of "what's wrong 
with rerunning the whole parse process?":

Well, first of all, why? It's the same damn thing that needs to get done, so 
what the hell's the point?

Secondly, templates and CTFE slow down the whole process. And being that 
those are two of D's killer features, their effect on compilation time is 
just going to get felt more and more.

And with that in mind, thirdly, every little bit of extra speed when 
building aids the whole modify/build/test cycle. It doesn't take the 
absurdly out-of-control C/C++-level build times to start hindering that 
cycle. Even shaving a 15 second build down to 10 seconds (and I would even 
argue the same point with lesser numbers than that) is enough to notably 
improve productivity.

And finally, if a lint tool is built into the compiler, and you really want 
compile and lint treated separately, and you don't care about duplicated 
processing, then all you have to do is change "dmd -w" to "dmd -w -c"/"dmd". 
So there you go: Eating cake and still having it.

I'll grant that rerunning the whole parse would be perfectly fine for an 
initial version of a lint tool, but as a permanent design it's just simply 
idiotic wasteful programming.