www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How DMD's -w *Prevents* Me From Seeing My Warnings

reply "Nick Sabalausky" <a a.a> writes:
Real-world example that's actually happened to me far too many times (and 
has *never* happened to me in any language other than D):

I'm writing app A and library B, both of which depend on an external library 
C. I compile A/B with -w to check for any warnings in my code. Either it has 
warnings and I fix them or it just simply passes.

Then, I make a change to A/B that brings in previously unused code from C 
(or I just simply update C), and this new code in C just happens to have 
something that triggers a warning (you can say "C should never release 
without fixing all warnings first" all you want, but the fact is: it still 
happens). I compile A/B again, and again I use -w to check for any warnings 
in the changes I made to A/B. Compiler spits out a warning on C and then (by 
design!) just plain craps out without 1. telling me a damn thing about my 
own code, or 2. actually building either A or B.

So now *I can't even compile* my A/B without either:

1. Waiting (and *hoping*) for a fix to C, both for my own sake and for the 
sake of all users of B and all people who want or need to compile A 
themselves.

2. Screwing up my schedule by detouring into making a fix for C, submitting 
it, and then for the sake of all users of B and the sake of all people who 
want or need to compile A themselves, wait for the fix to get accepted and 
incorporated into a new release of C.

3. (Something I'd still have to do anyway even if I go with option 1 or 
option 2): Entirely turning off the check for warnings.

Thus, -w's behavior has *prevented* me from seeing my warnings.

Royal PITA every single time. (And a <20 line trivial fix has been sitting 
in bugzilla for nearly a year, #2567, hell, I'll update and resubmit if 
that'll help get it in.)
Feb 10 2010
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Nick Sabalausky wrote:

 (you can say "C should never release 
 without fixing all warnings first" all you want, but the fact is: it still 
 happens).


How would the author of C check against all possible warnings in all
possible versions of all possible D compilers, including future versions
of these compilers?  Saying "C should never release without fixing all
warnings first" is equivalent to saying "C should never release".


-- 
Rainer Deyke - rainerd eldwood.com
Feb 10 2010
parent reply daoryn <adsfu afsd.ca> writes:
Rainer Deyke Wrote:


 Nick Sabalausky wrote:

 (you can say "C should never release 
 without fixing all warnings first" all you want, but the fact is: it still 
 happens).


 
 How would the author of C check against all possible warnings in all
 possible versions of all possible D compilers, including future versions
 of these compilers?  Saying "C should never release without fixing all
 warnings first" is equivalent to saying "C should never release".
 


You missed the point: theres an annoying bug in DMD and a fix has been
available for it for 1 year and its still accumulating dust on bugzilla.
The Original Author is not complaining about C's author, he's complaining about
a bug in the compiler.
Feb 11 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
daoryn wrote:

 You missed the point: theres an annoying bug in DMD and a fix has
 been available for it for 1 year and its still accumulating dust on
 bugzilla. The Original Author is not complaining about C's author,
 he's complaining about a bug in the compiler.


No, I completely agree with the original post.  '-w' is broken.  We all
know that.  I'm just forestalling any attempt to shift the blame to the
author of C.

A conforming D implementation is allowed to warn about anything it wants
to.  A conforming D implementation is not allowed to turn these warnings
into errors, because that breaks valid code.  Therefore DMD with '-w' is
not a conforming D implementation.


-- 
Rainer Deyke - rainerd eldwood.com
Feb 11 2010
parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:hl2204$pk2$1 digitalmars.com...

 daoryn wrote:

 You missed the point: theres an annoying bug in DMD and a fix has
 been available for it for 1 year and its still accumulating dust on
 bugzilla. The Original Author is not complaining about C's author,
 he's complaining about a bug in the compiler.


 No, I completely agree with the original post.  '-w' is broken.  We all
 know that.  I'm just forestalling any attempt to shift the blame to the
 author of C.

 A conforming D implementation is allowed to warn about anything it wants
 to.  A conforming D implementation is not allowed to turn these warnings
 into errors, because that breaks valid code.  Therefore DMD with '-w' is
 not a conforming D implementation.


Heh, I'm starting to think I should have chosen X, Y and Z for my example. 
Here am I reading replies to my own message, I come across "C's author" and 
I start thinking "K&R" (Argh, more letters! ;) )
Feb 11 2010
prev sibling next sibling parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 Real-world example that's actually happened to me far too many times (and 
 has *never* happened to me in any language other than D):
 
 I'm writing app A and library B, both of which depend on an external library 
 C. I compile A/B with -w to check for any warnings in my code. Either it has 
 warnings and I fix them or it just simply passes.
 
 Then, I make a change to A/B that brings in previously unused code from C 
 (or I just simply update C), and this new code in C just happens to have 
 something that triggers a warning (you can say "C should never release 
 without fixing all warnings first" all you want, but the fact is: it still 
 happens).


The idea of "optional errors" is nonsense. Especially for library 
developers, they are NOT optional.
Feb 10 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Royal PITA every single time. (And a <20 line trivial fix has been sitting 
 in bugzilla for nearly a year, #2567, hell, I'll update and resubmit if 
 that'll help get it in.)


This is a different way to address the issue. Warnings do not halt 
parsing/semantic passes, but dmd still exits with an error status if 
there were any warnings.

http://www.dsource.org/projects/dmd/changeset/382
Feb 12 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hl4hkj$2n7m$1 digitalmars.com...

 Nick Sabalausky wrote:

 Royal PITA every single time. (And a <20 line trivial fix has been 
 sitting in bugzilla for nearly a year, #2567, hell, I'll update and 
 resubmit if that'll help get it in.)


 This is a different way to address the issue. Warnings do not halt 
 parsing/semantic passes, but dmd still exits with an error status if there 
 were any warnings.

 http://www.dsource.org/projects/dmd/changeset/382


Ok, that is a big improvement (thanks!!!), but this still remains:

1. I compile my program, with warnings as I always do (because I want to be 
told about them, and as early as possible).
2. I fix all my errors, but I get a warning in an external library.
3. Now I have to go modify my build script and recompile just to get the 
output files that DMD arbitrarily refused to give me before (and then go 
edit my built script again to turn them back on). Which is not impossible, 
but it's all for...what benefit exactly? I mean, even if there were a 
legitimate reason for forcing any warnings to suppress output files (and I 
very much dispute that there is), the fact I can get the same damn output 
files anyway by shutting the warnings off and recompiling renders the whole 
"feature" pointless. You may as well just write the output files anyway and 
save people the bother of working around it.
Feb 12 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Nick,


 You may as well just write the output files anyway and
 save people the bother of working around it.


Vote ++;

Or maybe have "-w+" for the old fail-fast way, "-w" for the new way and "-w-" 
for the "show them and ignore them" way.

I'd also not mind see an orthogonal way to suppress warnings in libraries; 
maybe only do warnings in packages not reached via include paths give via -I

--
<IXOYE><
Feb 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff102dc8cc7a05ac37bc1a news.digitalmars.com...

 Hello Nick,


 You may as well just write the output files anyway and
 save people the bother of working around it.


 Vote ++;

 Or maybe have "-w+" for the old fail-fast way, "-w" for the new way and 
 "-w-" for the "show them and ignore them" way.


I'm not sure I can imagine even a perceived reason a person might want the 
old fail-fast way. So think that brings it down to "-w" and "-w-". And 
that's exactly what my old patch does, except it called it "-ww" instead of 
"-w-", but that's a trivial difference, and if "-w-"considered better than 
it's literally just a two-byte change (once for the actual param and once 
for the help/usage screen).


 I'd also not mind see an orthogonal way to suppress warnings in libraries; 
 maybe only do warnings in packages not reached via include paths give 
 via -I


I could live with or without that. If it were to be done, another idea is 
something like:

"-w+package_name" -> Turn on warnings for package "package_name" and all 
sub-packages
"-w-package_name" -> Turn off warnings for package "package_name" and all 
sub-packages
"-ww+package_name" -> Turn on (but ignore) warnings for package 
"package_name" and all sub-packages

That would give more control, but something closer to your way might be 
cleaner or more convenient.
Feb 12 2010
parent reply BCS <none anon.com> writes:
Hello Nick,


 "BCS" <none anon.com> wrote in message
 news:a6268ff102dc8cc7a05ac37bc1a news.digitalmars.com...
 

 Hello Nick,
 

 You may as well just write the output files anyway and save people
 the bother of working around it.
 


 Vote ++;
 
 Or maybe have "-w+" for the old fail-fast way, "-w" for the new way
 and "-w-" for the "show them and ignore them" way.
 


 I'm not sure I can imagine even a perceived reason a person might want
 the old fail-fast way.


If your getting lots of warnings? Or maybe your compile times are really 
long (I've seen template code run north of 5 min for a single file). Du'know.


 I'd also not mind see an orthogonal way to suppress warnings in
 libraries; maybe only do warnings in packages not reached via include
 paths give via -I
 


 I could live with or without that. If it were to be done, another idea
 is something like:
 
 "-w+package_name" -> Turn on warnings for package "package_name" and
 all sub-packages
 "-w-package_name" -> Turn off warnings for package "package_name" and
 all sub-packages
 "-ww+package_name" -> Turn on (but ignore) warnings for package
 "package_name" and all sub-packages

 That would give more control, but something closer to your way might
 be cleaner or more convenient.


I can't think of any reason to turn on warnings starting at any root other 
than the files listed on the command line and I can't think of any good reason 
to turn off warnings at any point that isn't a ownership or library boundary. 
I guess I'm saying I can't think of a case where your proposal gives me
anything 
I'd want.
 
--
<IXOYE><
Feb 12 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff102e38cc7a09ab4db24c news.digitalmars.com...

 Hello Nick,


 "BCS" <none anon.com> wrote in message
 news:a6268ff102dc8cc7a05ac37bc1a news.digitalmars.com...

 I'd also not mind see an orthogonal way to suppress warnings in
 libraries; maybe only do warnings in packages not reached via include
 paths give via -I


 I could live with or without that. If it were to be done, another idea
 is something like:

 "-w+package_name" -> Turn on warnings for package "package_name" and
 all sub-packages
 "-w-package_name" -> Turn off warnings for package "package_name" and
 all sub-packages
 "-ww+package_name" -> Turn on (but ignore) warnings for package
 "package_name" and all sub-packages

 That would give more control, but something closer to your way might
 be cleaner or more convenient.


 I can't think of any reason to turn on warnings starting at any root other 
 than the files listed on the command line


Good point. So scratch the "-w+package_name" and "-ww+package_name" parts.


 and I can't think of any good reason to turn off warnings at any point 
 that isn't a ownership or library boundary.


Neither can I, but how else is the compiler going to know where those 
boundaries are if not via a package/module name? The more I think about it, 
the more convinced I am that going by "included via -I or not?" is a bad 
idea, because even I've included third-party code without -I and included my 
own code with -I, and had reason (or at least "good enough" reason anyway) 
to do so.
Feb 12 2010
parent BCS <none anon.com> writes:
Hello Nick,


 Neither can I, but how else is the compiler going to know where those
 boundaries are if not via a package/module name? The more I think
 about it, the more convinced I am that going by "included via -I or
 not?" is a bad idea, because even I've included third-party code
 without -I and included my own code with -I, and had reason (or at
 least "good enough" reason anyway) to do so.


OK, I'll give you that one. I wasn't thinking of other ways that -I (or not) 
could be used.

--
<IXOYE><
Feb 12 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-12 17:20:33 -0500, BCS <none anon.com> said:


 I'd also not mind see an orthogonal way to suppress warnings in 
 libraries; maybe only do warnings in packages not reached via include 
 paths give via -I


I think the simplest thing would be to get warnings only for the code 
you're actually compiling. If you're compiling only one file called 
"test.d", then you get warnings for everything in "test.d" and 
templates instantiated from "test.d". All the rest is just imported 
declarations and you should't see warnings about imported declarations. 
You'll have to compile the other modules too if they're not in a 
separate library anyway, and then you'll be able to see the warnings it 
generates.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 12 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Ok, that is a big improvement (thanks!!!), but this still remains:
 
 1. I compile my program, with warnings as I always do (because I want to be 
 told about them, and as early as possible).
 2. I fix all my errors, but I get a warning in an external library.
 3. Now I have to go modify my build script and recompile just to get the 
 output files that DMD arbitrarily refused to give me before (and then go 
 edit my built script again to turn them back on). Which is not impossible, 
 but it's all for...what benefit exactly? I mean, even if there were a 
 legitimate reason for forcing any warnings to suppress output files (and I 
 very much dispute that there is), the fact I can get the same damn output 
 files anyway by shutting the warnings off and recompiling renders the whole 
 "feature" pointless. You may as well just write the output files anyway and 
 save people the bother of working around it.


Here's how I set up a makefile to build with different options:

----------------------------
FLAGS=

foo : foo.d
     dmd foo $(FLAGS)

warnings :
     make FLAGS=-w
----------------------------

Use
	make

to do a regular build, and

	make warnings

to do a warnings build. You don't have to edit things. Having make 
recursively call itself setting various options on and off is a compact 
and easy way to do it. I use this all the time for various kinds of builds.

So, for your case, I'd "make warnings", fix all the warnings that I 
intend to, then just do "make" for the executable build.

As for why warnings don't just slide through without creating any 
errors, I'll give my usual rant on them:

If they go ahead and produce the output files anyway, you never see 
them! They scroll up and off your window, you don't notice them. Your 
automated build system never notices them, and happily reports that 
everything went swimmingly.

Your difficulty with the 3rd party library warnings is a classic example 
of why I spent a lot of energy resisting having warnings in the language 
in the first place.
Feb 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hl4krg$2uku$1 digitalmars.com...

 Nick Sabalausky wrote:

 Ok, that is a big improvement (thanks!!!), but this still remains:

 1. I compile my program, with warnings as I always do (because I want to 
 be told about them, and as early as possible).
 2. I fix all my errors, but I get a warning in an external library.
 3. Now I have to go modify my build script and recompile just to get the 
 output files that DMD arbitrarily refused to give me before (and then go 
 edit my built script again to turn them back on). Which is not 
 impossible, but it's all for...what benefit exactly? I mean, even if 
 there were a legitimate reason for forcing any warnings to suppress 
 output files (and I very much dispute that there is), the fact I can get 
 the same damn output files anyway by shutting the warnings off and 
 recompiling renders the whole "feature" pointless. You may as well just 
 write the output files anyway and save people the bother of working 
 around it.


 Here's how I set up a makefile to build with different options:


....

 So, for your case, I'd "make warnings", fix all the warnings that I intend 
 to, then just do "make" for the executable build.


I already have "make debug" (for normal development, and it's ***with all 
warnings*** because, after all, its for *my normal development* and 
obviously I want to see any problems as soon as possible) and "make release" 
(for distribution)...so far...

Since that one null-checking feature only happens with optimizations 
enabled, I have to add the optimization flag to my debug build, which means 
that I'm also going to have to make a new "make debuggable_debug" for when 
I, or anyone else, wants to use a debugger on my apps.

And now I'm *also* expected to add on top of all that "make debug_nowarn" 
for whenever a warning shows up, and, naturally, a "make 
debuggable_debug_nowarn" for when I, or someone, wants to use a debugger 
during a time when an outside library has a warning.

And of course, I now have to do a recompile any time I need to switch 
between any of the ever-growing plethora of so-called "debug" builds. And 
keep in mind too, like *many* people, I don't build form the command-line, I 
set up an tool in my editor, and believe me, that tool list is getting 
fucking looong. All these extra build configurations are just simply a 
completely unnecessary mess.

And yet, were it not for DMD, there would be no reason I couldn't just keep 
it a nice simple "debug" vs "release" like I can with every other damn 
compiler on the planet.


 As for why warnings don't just slide through without creating any errors, 
 I'll give my usual rant on them:

 If they go ahead and produce the output files anyway, you never see them! 
 They scroll up and off your window, you don't notice them. Your automated 
 build system never notices them, and happily reports that everything went 
 swimmingly.


If someone has that problem, they can just stick with the default "warnings 
as errors". In my setup, I don't have that problem, so why should *I* who 
*does* see them without them scrolling off the screen, not be able to 
choose? If you add in the "warnings as warnings" option, then by *actively* 
turning that on, they're asserting that they either do see warnings in their 
setup like I do or it's their own damn problem.

Plus, you're really worried about scrolling, you can also have an "Exited 
with X error(s), and Y warning(s)" summany at the end like MSVC has had for 
decades.


 Your difficulty with the 3rd party library warnings is a classic example 
 of why I spent a lot of energy resisting having warnings in the language 
 in the first place.


An admirable idea, but I think D's proven that strategy just doesn't work in 
practice.
Feb 12 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 An admirable idea, but I think D's proven that strategy just doesn't work in 
 practice.



http://www.dsource.org/projects/dmd/changeset/384
Feb 13 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hl7a1u$rot$1 digitalmars.com...

 Nick Sabalausky wrote:

 An admirable idea, but I think D's proven that strategy just doesn't work 
 in practice.



 http://www.dsource.org/projects/dmd/changeset/384



Hooray!!!!!!

Thank you Walter!!!!
Feb 13 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Hooray!!!!!!
 
 Thank you Walter!!!!


You're welcome. This is obviously a serious issue for you, and trivial 
to implement.
Feb 13 2010
prev sibling parent Janzert <janzert janzert.com> writes:
Walter Bright wrote:

 Nick Sabalausky wrote:

 An admirable idea, but I think D's proven that strategy just doesn't
 work in practice.


 
 
 http://www.dsource.org/projects/dmd/changeset/384


Woot, Thank you. This relieves a source of pain using DMD.

Janzert
Feb 15 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Nick Sabalausky wrote:

 Ok, that is a big improvement (thanks!!!), but this still remains:

 1. I compile my program, with warnings as I always do (because I want 
 to be told about them, and as early as possible).
 2. I fix all my errors, but I get a warning in an external library.
 3. Now I have to go modify my build script and recompile just to get 
 the output files that DMD arbitrarily refused to give me before (and 
 then go edit my built script again to turn them back on). Which is not 
 impossible, but it's all for...what benefit exactly? I mean, even if 
 there were a legitimate reason for forcing any warnings to suppress 
 output files (and I very much dispute that there is), the fact I can 
 get the same damn output files anyway by shutting the warnings off and 
 recompiling renders the whole "feature" pointless. You may as well 
 just write the output files anyway and save people the bother of 
 working around it.


 
 Here's how I set up a makefile to build with different options:
 
 ----------------------------
 FLAGS=
 
 foo : foo.d
     dmd foo $(FLAGS)
 
 warnings :
     make FLAGS=-w
 ----------------------------
 
 Use
     make
 
 to do a regular build, and
 
     make warnings
 
 to do a warnings build.


Do you even need to define FLAGS at the top of the file?

Andrei
Feb 12 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Do you even need to define FLAGS at the top of the file?


No, but I don't particularly like implicitly defined variables!
Feb 12 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
<snip>

 Use
     make
 
 to do a regular build, and
 
     make warnings


<snip>

Problem with having them as two separate build modes for the whole project:

Let's call my modules X and Y.  X depends on a library module, call it 
Z.  Z triggers a warning.  I've ridden X of warnings, now it's time to 
look at Y.  However, compiling X will still fail because of the warnings 
in Z and, because of the build sequence, this stops Y from being checked 
for warnings.

How about having an option whereby warnings cause the compiler to emit 
an error code but still generate the .obj?  That way, the user can 
choose to ignore the warnings in that one module by just running make again.

Having warnings generated only for the module being compiled and not 
modules it imports would solve most cases of this but, when the library 
code is a template, I can see there being cases where you'd want the 
warnings and cases where you'd want to ignore them.

Stewart.
Feb 12 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Nick Sabalausky wrote:

 3. Now I have to go modify my build script and recompile just to get the 
 output files that DMD arbitrarily refused to give me before (and then go 
 edit my built script again to turn them back on). Which is not impossible, 
 but it's all for...what benefit exactly?


Or modify your build script to always compile twice, once with warnings
and once without.  It's ugly and stupid, but it's also simple to do and
it works.


 I mean, even if there were a 
 legitimate reason for forcing any warnings to suppress output files (and I 
 very much dispute that there is), the fact I can get the same damn output 
 files anyway by shutting the warnings off and recompiling renders the whole 
 "feature" pointless. You may as well just write the output files anyway and 
 save people the bother of working around it.


That would be ideal, of course.


-- 
Rainer Deyke - rainerd eldwood.com
Feb 12 2010
parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:hl4p26$5rk$1 digitalmars.com...

 Nick Sabalausky wrote:

 3. Now I have to go modify my build script and recompile just to get the
 output files that DMD arbitrarily refused to give me before (and then go
 edit my built script again to turn them back on). Which is not 
 impossible,
 but it's all for...what benefit exactly?


 Or modify your build script to always compile twice, once with warnings
 and once without.  It's ugly and stupid, but it's also simple to do and
 it works.


And it's needlessly slow, too. But yea, you're right on all counts, though.


 I mean, even if there were a
 legitimate reason for forcing any warnings to suppress output files (and 
 I
 very much dispute that there is), the fact I can get the same damn output
 files anyway by shutting the warnings off and recompiling renders the 
 whole
 "feature" pointless. You may as well just write the output files anyway 
 and
 save people the bother of working around it.


 That would be ideal, of course.
Feb 12 2010