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 

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 

 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 

 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