www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Regarding compiler switches

reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
DMD has just a few switches that control how code is compiled, such as 
-safe, -release, -O and so on. In comparison, GCC has (and this is just 
a rough estimate) a gazillion switches. For the most part, DMD's simpler 
approach is a good thing, because it makes the compiler easy to use.

However, from time to time, discussions appear on this NG that indicate 
not everyone is happy with the situation. For instance, people have 
complained that it's not possible to separately turn on/off bounds 
checking and compilation of contracts.

Recently there was a discussion of whether the -safe switch should 
affect array bounds checking too. I don't think any agreement was reached.

Is there any good reason for NOT letting people choose these things for 
themselves? I suspect it would be very easy to add more detailed options 
to DMD:

   --bounds-checking=on|off
   --mem-safe=on|off
   --Oxxx=on|off|auto  (There are many possible optimisations, and the
                       compiler doesn't always know best.)
   --contracts=on|off

Note that I think it's important that -release & co. are kept, but they 
should be defined as common combinations of the more detailed options.

-Lars
Nov 05 2009
next sibling parent Justin Johansson <free beer.com> writes:
Lars T. Kyllingstad Wrote:

 DMD has just a few switches that control how code is compiled, such as 
 -safe, -release, -O and so on. In comparison, GCC has (and this is just 
 a rough estimate) a gazillion switches. For the most part, DMD's simpler 
 approach is a good thing, because it makes the compiler easy to use.
 
 However, from time to time, discussions appear on this NG that indicate 
 not everyone is happy with the situation. For instance, people have 
 complained that it's not possible to separately turn on/off bounds 
 checking and compilation of contracts.
 
 Recently there was a discussion of whether the -safe switch should 
 affect array bounds checking too. I don't think any agreement was reached.
 
 Is there any good reason for NOT letting people choose these things for 
 themselves? I suspect it would be very easy to add more detailed options 
 to DMD:
 
    --bounds-checking=on|off
    --mem-safe=on|off
    --Oxxx=on|off|auto  (There are many possible optimisations, and the
                        compiler doesn't always know best.)
    --contracts=on|off
 
 Note that I think it's important that -release & co. are kept, but they 
 should be defined as common combinations of the more detailed options.
 
 -Lars

Lars, you raise a few good points about compiler switches in general. With better --help and/or doco I would not have resorted to asking the following question on D.learn. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=18101 The impetus for my particular post was a quandary I had about why asserts were being fired in my D program when the -release option was specified on the command line. Upon some kind person replying on D.learn I revisited my command line only to realise I had -unittest flicked on as well as -release. If you read that thread you will see my final response. beers, Justin btw. beers comes about because of an almost typo on 'cheers' for an NG posting but since I now kind of like it -- and I'd be happy to buy you a cheer -- I'm thinking of making my D NG signature beerophile but the USPTO might rule this as being too close to another name already in use in this community :-) ciao, beerophile
Nov 05 2009
prev sibling next sibling parent reply Michal Minich <michal.minich gmail.com> writes:
Hello Lars,

 DMD has just a few switches that control how code is compiled, such as
 -safe, -release, -O and so on. In comparison, GCC has (and this is
 just a rough estimate) a gazillion switches. For the most part, DMD's
 simpler approach is a good thing, because it makes the compiler easy
 to use.
 
 However, from time to time, discussions appear on this NG that
 indicate not everyone is happy with the situation. For instance,
 people have complained that it's not possible to separately turn
 on/off bounds checking and compilation of contracts.
 
 Recently there was a discussion of whether the -safe switch should
 affect array bounds checking too. I don't think any agreement was
 reached.
 
 Is there any good reason for NOT letting people choose these things
 for themselves? I suspect it would be very easy to add more detailed
 options to DMD:
 
 --bounds-checking=on|off
 --mem-safe=on|off
 --Oxxx=on|off|auto  (There are many possible optimisations, and the
 compiler doesn't always know best.)
 --contracts=on|off
 Note that I think it's important that -release & co. are kept, but
 they should be defined as common combinations of the more detailed
 options.
 
 -Lars
 

Separate switches for bounds checking and contracts would be good (which would turn of bounds checking for mem-safe code too). But there is no reason to have mem-safe=on switch - you cannot force safety on unsafe code by compiler switch, this just would not compile. I think the proper way to specify memory safety is per function, as I wrote in other post around here. Also, I think there is only one -O in dmd.
Nov 05 2009
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Michal Minich wrote:
 Hello Lars,
 
 DMD has just a few switches that control how code is compiled, such as
 -safe, -release, -O and so on. In comparison, GCC has (and this is
 just a rough estimate) a gazillion switches. For the most part, DMD's
 simpler approach is a good thing, because it makes the compiler easy
 to use.

 However, from time to time, discussions appear on this NG that
 indicate not everyone is happy with the situation. For instance,
 people have complained that it's not possible to separately turn
 on/off bounds checking and compilation of contracts.

 Recently there was a discussion of whether the -safe switch should
 affect array bounds checking too. I don't think any agreement was
 reached.

 Is there any good reason for NOT letting people choose these things
 for themselves? I suspect it would be very easy to add more detailed
 options to DMD:

 --bounds-checking=on|off
 --mem-safe=on|off
 --Oxxx=on|off|auto  (There are many possible optimisations, and the
 compiler doesn't always know best.)
 --contracts=on|off
 Note that I think it's important that -release & co. are kept, but
 they should be defined as common combinations of the more detailed
 options.

 -Lars

Separate switches for bounds checking and contracts would be good (which would turn of bounds checking for mem-safe code too). But there is no reason to have mem-safe=on switch - you cannot force safety on unsafe code by compiler switch, this just would not compile. I think the proper way to specify memory safety is per function, as I wrote in other post around here.

There is already a -safe switch, and whether that is reasonable or not is a completely different discussion. My point was that instead of discussing whether -safe should also force array bounds checking, there should be separate switches for the two: --mem-safe - Does what -safe was originally intended to do. --bounds-checking - Does what you think it does. --safe - The most commonly used combination of the above, I really don't care which, because now I'm free to choose for myself.
 Also, I think there is only one -O in dmd.

And I'm saying there should be more, for the cases where the programmer actually knows best. (It happens!) In the case of optimisations, there could actually be three levels of detail: High-level: -O - Equivalent to setting all other switches to 'auto'. The compiler makes all the decisions (like the current -O). Middle level: --Ospeed - Optimise for speed. The compiler decides how to do this in the best way possible. --Omem - Like above, but optimise for minimal memory usage. Low-level: --Oxxx=on|off|auto I'm not even going to start listing the possible low-level optimisation options, and I don't necessarily think we should go the down the GCC road, but have a look: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html -Lars
Nov 05 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 Is there any good reason for NOT letting people choose these things for 
 themselves? I suspect it would be very easy to add more detailed options 
 to DMD:
 
    --bounds-checking=on|off
    --mem-safe=on|off
    --Oxxx=on|off|auto  (There are many possible optimisations, and the
                        compiler doesn't always know best.)
    --contracts=on|off

LDC has: -enable-asserts - (*) Enable assertions -enable-boundscheck - (*) Enable array bounds checks -enable-contracts - (*) Enable function pre- and post-conditions Options marked with (*) also have a -disable-FOO variant with inverted Bye, bearophile
Nov 05 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:hcu5bc$at8$1 digitalmars.com...
 DMD has just a few switches that control how code is compiled, such 
 as -safe, -release, -O and so on. In comparison, GCC has (and this is just 
 a rough estimate) a gazillion switches. For the most part, DMD's simpler 
 approach is a good thing, because it makes the compiler easy to use.

 However, from time to time, discussions appear on this NG that indicate 
 not everyone is happy with the situation. For instance, people have 
 complained that it's not possible to separately turn on/off bounds 
 checking and compilation of contracts.

 Recently there was a discussion of whether the -safe switch should affect 
 array bounds checking too. I don't think any agreement was reached.

 Is there any good reason for NOT letting people choose these things for 
 themselves? I suspect it would be very easy to add more detailed options 
 to DMD:

   --bounds-checking=on|off
   --mem-safe=on|off
   --Oxxx=on|off|auto  (There are many possible optimisations, and the
                       compiler doesn't always know best.)
   --contracts=on|off

 Note that I think it's important that -release & co. are kept, but they 
 should be defined as common combinations of the more detailed options.

Sounds like a good time to nag again about the idea of a "treat warnings as warnings" option: http://d.puremagic.com/issues/show_bug.cgi?id=2567 A patch is even there that adds "-ww" as an alternative to "-w" that enables warnings, but actually treats them as warnings. I *really* hate that DMD doesn't currently offer an ability to enable warnings without treating them as errors, because the current way amounts to nothing more than "optional errors", which effectively splits D into two different languages (and those two languages are a slightly less helpful one, and a somewhat naggy one, but the option to treat warnings as warnings would merge them back into the same language while maintaining the best of both).
Nov 05 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Sabalausky wrote:
 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
 news:hcu5bc$at8$1 digitalmars.com...
 DMD has just a few switches that control how code is compiled, such 
 as -safe, -release, -O and so on. In comparison, GCC has (and this is just 
 a rough estimate) a gazillion switches. For the most part, DMD's simpler 
 approach is a good thing, because it makes the compiler easy to use.

 However, from time to time, discussions appear on this NG that indicate 
 not everyone is happy with the situation. For instance, people have 
 complained that it's not possible to separately turn on/off bounds 
 checking and compilation of contracts.

 Recently there was a discussion of whether the -safe switch should affect 
 array bounds checking too. I don't think any agreement was reached.

 Is there any good reason for NOT letting people choose these things for 
 themselves? I suspect it would be very easy to add more detailed options 
 to DMD:

   --bounds-checking=on|off
   --mem-safe=on|off
   --Oxxx=on|off|auto  (There are many possible optimisations, and the
                       compiler doesn't always know best.)
   --contracts=on|off

 Note that I think it's important that -release & co. are kept, but they 
 should be defined as common combinations of the more detailed options.

Sounds like a good time to nag again about the idea of a "treat warnings as warnings" option: http://d.puremagic.com/issues/show_bug.cgi?id=2567 A patch is even there that adds "-ww" as an alternative to "-w" that enables warnings, but actually treats them as warnings. I *really* hate that DMD doesn't currently offer an ability to enable warnings without treating them as errors, because the current way amounts to nothing more than "optional errors", which effectively splits D into two different languages (and those two languages are a slightly less helpful one, and a somewhat naggy one, but the option to treat warnings as warnings would merge them back into the same language while maintaining the best of both).

NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! N N NNN NNN NN N N N NNN N N N N N NNN N NN N N N N NNN N That is an amazingly shit idea. Have you *ever* tried to write portable c++ code??? It's utterly impossible without prefixing and postfixing *every* single header filer with the following shit: ==================== /** my wanky library */ #include "disableWarningsForThisShittyCompiler.h" ... /*** stuff in my library that doesn't make clients want to eat their own fists and hunt me down and rape me with a bronze casting of a pinapple. **/ ... #include "reenableWarningsIDisabledSoImNotAMassiveCockToClients.h" ==================== I've never come across one single *useable* c or c++ library that doesn't not follow the above pattern. And don't give me that shit about command line options. That simply doesn't work. As a library implementor you have no control over that so you simply *have* to use *compiler* specific pragmas on every single bloody *compiler*. Warnings are BAD language design, nothing more. If you want warnings that are not errors, you need to write yourself a LINT style tool to run after you compile and lump it in with your test harness so they can be reviewed on a semi regular basis instead of annoying the shit out of you on every single compile. I've only had the misfortune to shepard code through 3 generations of Microsoft compiler and even with confining code to the compiler of 1 implementer it's a *massive* pain in the arse. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK82EyT9LetA9XoXwRAnLpAJoDEWlr/DuLh8e+ZsGCbjW6CVsR2QCeLzoX FT2qowHpKoBHKpvkOwZkHt0= =SiXu -----END PGP SIGNATURE-----
Nov 05 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"div0" <div0 users.sourceforge.net> wrote in message 
news:hcvnfd$pmq$1 digitalmars.com...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Nick Sabalausky wrote:
 Sounds like a good time to nag again about the idea of a "treat warnings 
 as
 warnings" option:

 http://d.puremagic.com/issues/show_bug.cgi?id=2567

 A patch is even there that adds "-ww" as an alternative to "-w" that 
 enables
 warnings, but actually treats them as warnings. I *really* hate that DMD
 doesn't currently offer an ability to enable warnings without treating 
 them
 as errors, because the current way amounts to nothing more than "optional
 errors", which effectively splits D into two different languages (and 
 those
 two languages are a slightly less helpful one, and a somewhat naggy one, 
 but
 the option to treat warnings as warnings would merge them back into the 
 same
 language while maintaining the best of both).

NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! NO. NO. NO. NO! N N NNN NNN NN N N N NNN N N N N N NNN N NN N N N N NNN N That is an amazingly shit idea. Have you *ever* tried to write portable c++ code??? It's utterly impossible without prefixing and postfixing *every* single header filer with the following shit: [more stuff involving how much of a pain warnings can be on C/C++]

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. 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? 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. 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.
Nov 05 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Sabalausky wrote:
 "div0" <div0 users.sourceforge.net> wrote in message 
 news:hcvnfd$pmq$1 digitalmars.com...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Nick Sabalausky wrote:
 Sounds like a good time to nag again about the idea of a "treat warnings 
 as
 warnings" option:

 http://d.puremagic.com/issues/show_bug.cgi?id=2567

 A patch is even there that adds "-ww" as an alternative to "-w" that 
 enables
 warnings, but actually treats them as warnings. I *really* hate that DMD
 doesn't currently offer an ability to enable warnings without treating 
 them
 as errors, because the current way amounts to nothing more than "optional
 errors", which effectively splits D into two different languages (and 
 those
 two languages are a slightly less helpful one, and a somewhat naggy one, 
 but
 the option to treat warnings as warnings would merge them back into the 
 same
 language while maintaining the best of both).

N N NNN NNN NN N N N NNN N N N N N NNN N NN N N N N NNN N That is an amazingly shit idea. Have you *ever* tried to write portable c++ code??? It's utterly impossible without prefixing and postfixing *every* single header filer with the following shit: [more stuff involving how much of a pain warnings can be on C/C++]

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.
 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?
 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. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK9ECHT9LetA9XoXwRAgnzAJ4wcW5P4hK8uAzi+3jeo56SpwszrwCg0NJl acwgR+zlMO3wECxZRS0QTf4= =YN30 -----END PGP SIGNATURE-----
Nov 06 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"div0" <div0 users.sourceforge.net> wrote in message 
news:hd1fa2$1e20$1 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.
Nov 06 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hd27ti$8st$1 digitalmars.com...
 You're missing my point. To briefly reiterate: I proposed adding an 
 optional switch to let people treat warnings as errors, and...

Shit, I should proof-read better. I meant, of course, "an optional switch to let people *NOT* treat warnings as errors".
Nov 06 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hd27ti$8st$1 digitalmars.com...

 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.

In fact, attached is a preliminary version of a separate DLint tool for your enjoyment. It's Win-only but should be trivial to port to bash.
Nov 06 2009
prev sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Sabalausky wrote:

 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*.

Ok fair dos, I agree with you that warnings should [not exist at all] be warnings not errors. But if you like warnings so much please provide a concrete example of a compilation run that's given you a useful warning that you've then used to correct a problem with your code. For me doing C++ with visual studio, the only time that has happened is: ==== if(true); ==== {WARNING} main.cpp(47) : warning C4390: ';' : empty controlled statement found; is this the intent? ==== Do the same with DMD: ==== if(true); ==== {ERROR} test.d(2): use '{ }' for an empty statement, not a ';' ==== For every situation I believe that there is a simple and unambiguous right/wrong choice and D's design pretty much does away with all those pointless warnings and it makes stupid things errors. As another for instance, WB decided that shadowing variable names are wrong and has disallowed them. Now I personally disagree with that choice as I've never been bitten by a bug that has caused and I also tend to write code which does quite a bit of shadowing declarations. However making the choice to make it an error rather than a warning is definitely correct as far as I'm concerned. Errors get corrected (because you have to) and warnings get ignored. I've spent 100s of hours over the past 8 years where I work fixing shitty code written by dribbling morons who couldn't be bothered to fix the warnings that their code generated and who quite frankly should never have been employed in the first place. Given the fact that you are a NG posting, D loving weirdo your code is probably very good and well documented and probably it compiles with out generating any warnings at all, but you and the code you write is rare & odd. Most of the code that's done out there by 'normal programmers' whose only concern is getting paid at the end of the month basically sucks, so making things errors, which they have to fix rather than warnings is the way to go, from my pragmatic working coders point of view. Though I suppose you can throw the lint tool argument right back at me and say that people that employee morons should run a lint tool.
 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 :/.

lol. I know what you mean, my todo list is growing at an exponential rate. By the time I die, I'm going to need at least 4 more lifetimes to catch up on it.
 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.

Always a problem. Maybe a patch which does your new idea would have a better chance though, as that way people would have the best of both worlds.
 
 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.

True, but that is all front end stuff and the front end is open source so doing a lint tool would be easy for anybody who feels that strongly about it.
 
 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?

Well one point is, CPU time is very cheap, human time is very expensive.
 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.

really? what's the maximum time you've waited for dmd to finish compiling? I've never seen it take more than a 1 second; however my D apps aren't big or complicated so maybe I've not run into your problems.
 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.

Sorry but I think that's rubbish. In my experience 99% of developer time is spent either debugging problems, sat at a desk scribbling diagrams and solving problems or being on the phone to the client. If saving a few second during a compilation really improves your productivity you must be a really crappy programmer, which can't be true; you are obviously not that stupid.
 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.

Good point, but then you need to persuade Walter to support all that lint functionality which would be redundant if the language was sufficiently well specified. I'd rather see the effort put into closing off the corner cases, maybes and undefined functionally.
 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.

? I really don't understand your reluctance to burn cpu cycles. To me you seem to be suffering from a bad case of premature optimisation. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK9OAVT9LetA9XoXwRAs26AJ9Ij4R4Uq2ID9Q7zyIsjdri4LjVqgCgwcWJ OyKORD8JdJGzY5CtPWjyjdY= =1SK1 -----END PGP SIGNATURE-----
Nov 06 2009
parent "Nick Sabalausky" <a a.a> writes:
"div0" <div0 users.sourceforge.net> wrote in message 
news:hd2n6e$135m$1 digitalmars.com...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Nick Sabalausky wrote:

 Ok fair dos, I agree with you that warnings should [not exist at all] be
 warnings not errors.

Ok, I'm glad that we at least agree on that.
 But if you like warnings so much please provide a concrete example of a
 compilation run that's given you a useful warning that you've then used
 to correct a problem with your code.

First of all, not all of it is necessarily about identifying a problem that already exists. Some of it, like getting a "switch statement has no default" when switching on an enum has more to do with defensive coding and making sure the code properly handles a non-local change sometime in the future (ie, adding an new enum value). Secondly, see below...
 For every situation I believe that there is a simple and unambiguous
 right/wrong choice and D's design pretty much does away with all those
 pointless warnings and it makes stupid things errors.

I think that's overly idealistic. I absolutely agree that warnings should be minimized in favor of a clearly defined "ok" vs "error" whenever reasonably possible, and that D has done great in this regard, but I definitely don't think it's always reasonably possible. Sometimes deciding "that is allowed" will cause potential problems to go unnoticed and deciding that the same thing should be an error instead just simply causes more trouble than it's worth. There isn't always a good decision, or, if there is, it might just not be practical for other reasons. For instance: DMD's "no return at end of function" warning. That definitely has saved me from runtime bugs. There have been times when I got that warning, and saw that I had built up a return value but forgot to return it, and definitely didn't want to be returning T.init. "Ok, so the language definition should require a return at the end of a non-void function, and to omit it would be an error." Nice try, but then the language becomes a pain in the ass whenever you have something that's guaranteed to either throw or return a value before the final closing curly brace. "The obvious correct solution is flow analysis." Great, except 1. Perfect flow analysis can be impractically slow, and 2. It a big feature that'll take time to implement, plus there are more pressing matters on the table, so what are you supposed to do in the meantime? "Then for the meantime, just pick 'ok' or 'error'." First of all, at that point, the whole idea that "for every situation [...] there is a simple and unambiguous right/wrong choice" has pretty much already come crashing down. It was a great idea while it lasted, just like "everyone should always get along", but the real world just doesn't work that way, even as much as I would love for it to. Secondly, nobody's going to agree which way to go anyway, so...you call the damn thing a warning and move on. And that's pretty much just what happened. An unenviable, but nevertheless good, move on Walter's part. I can make a similar case for "statement is not reachable": There *have been* times when I've had code that needed to get executed, but was within a section that, due to an oversight, was dead code. The language could have just outlawed such dead code, but that's just a serious pain when debugging. There *have been* times when I deliberately stuck a premature, unconditional and temporary return statement (or throw) in the middle of a function for the sake of debugging. I knew it caused dead code, and I didn't care, and a non-fatal warning wouldn't have bothered anyone because I knew damn well I was just going to remove it in a minute or two anyway (I have ways to make sure such temporary things actually do get removed). So if dead code had been declared an error, I would have had to temporarily comment it all out just to shut the stupid compiler up.
 I've spent 100s of hours over the past 8 years where I work fixing
 shitty code written by dribbling morons who couldn't be bothered to fix
 the warnings that their code generated and who quite frankly should
 never have been employed in the first place.

 Given the fact that you are a NG posting, D loving weirdo your code is
 probably very good and well documented and probably it compiles with out
 generating any warnings at all, but you and the code you write is rare &
 odd.

 Most of the code that's done out there by 'normal programmers' whose
 only concern is getting paid at the end of the month basically sucks, so
 making things errors, which they have to fix rather than warnings is the
 way to go, from my pragmatic working coders point of view.

 Though I suppose you can throw the lint tool argument right back at me
 and say that people that employee morons should run a lint tool.

I've worked at such places as well. It really is very depressing :(. Although I don't think "lint tool" is the right solution in that case (although it might help somewhat). The real solution is take the idiot who keeps hiring idiots in the first place, and kick his worthless ass out to the curb (it was probably just one of those "recruiters [or managers] who use grep" anyway, if you read Joel On Software). Unfortunately, in my experience, the stupidity in such places usually goes all the way to the top (or at least somewhere above the glass ceiling beyond which us mere worker peasants hath no right to look upon or speaketh to hallowed upper management), so in those cases it doesn't matter what the language designers do, those people are just going to find new ways to thoroughly fuck everything up anyway (like mandate VBScript, or name a loading function "save", or have the asshole salesmen promise new features to new customers before the development team even hears about it, let alone actually have it in existence, and then blame the devs when things inevitably don't work out - and these were all just one specific company - and doesn't even amount to half of the crap they pulled in the mere one year I was there). And I do really mean all that, I'm not using any hyperbole (well, okay, maybe the "peasant" and "hallowed" stuff was embellished a little bit - but only in word choice, not actual overall meaning).
 lol. I know what you mean, my todo list is growing at an exponential
 rate. By the time I die, I'm going to need at least 4 more lifetimes to
 catch up on it.

Very well-put. One of the reasons I sometimes wish I were Vulcan, or better yet, a Trill symbiote ;)
 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.

Always a problem. Maybe a patch which does your new idea would have a better chance though, as that way people would have the best of both worlds.

Yea, that is a good point. (I hope ;) )
 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.

True, but that is all front end stuff and the front end is open source so doing a lint tool would be easy for anybody who feels that strongly about it.

Oh right, certainly. But it still simply just isn't there right now, so in the meantime all we have is DMD (or LDC) itself...
 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?

Well one point is, CPU time is very cheap, human time is very expensive.

I've heard the CPU/programmer time-economics argument many times, and the more I hear it the more convinced I get it's a load of crap. Or at least overstated/oversimplified. For one thing, unless all the code you're writing is entirely specific to a custom program that's only going to get used by a handful of people a handful of times, then you have to multiply the CPU cost by the number of users and frequency of usage to get a meaningfully comparable figure. At the very least, blindly ranking one's own (or one's company's own) programmer time higher than CPU time of the product is extremely disrespectful to the users. And anyone who disregards the consequences of disrespect to users/clients/customers is a terrible manager in both ethics *and* bottom-line results. Sure, some companies have been able to compensate in other ways for the financial effects of their blatant disrespect to society, but it's still a factor that's working against them But even besides that, the whole CPU-time versus programmer-time argument isn't even applicable in this case: For something like a build process, CPU time *IS* programmer time. After all, what the heck is the programmer doing while the CPU is using it's CPU time? Being productive? Hell no, he's just sitting there loosing his state of flow. In fact, there isn't anything else he *can* do without putting his flow in even further jeopardy. And that flow is one of the most important factors in programmer productivity, if not the single most.
 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.

really? what's the maximum time you've waited for dmd to finish compiling? I've never seen it take more than a 1 second; however my D apps aren't big or complicated so maybe I've not run into your problems.

The app I just happen to be working on at the moment takes about 12 seconds to compile with DMD (4 seconds if nothing has changed). And it's only a medium-sized program at most (at least if you count the libraries I've built that it uses: exclude them and it's less than 500 lines, but that's probably not a fair way to count it). A full build of all executables in the project that it's part of takes, umm, let's see...1 min 44 sec, and actually that's just the windows build, I also do linux builds (although usually only when putting out a new release). Granted I could probably cut that "build everything" figure down significantly if incremental building worked reliably...and switching to xfbuild might help a little (currently using rebuild 0.76 with oneatatime turned off), although xfbuild gets it's speed by avoiding duplicated parsing which is exactly what I'm defending here. But anyway, those are the build times I'm getting right now.
 Sorry but I think that's rubbish. In my experience 99% of developer time
 is spent either debugging problems, sat at a desk scribbling diagrams
 and solving problems or being on the phone to the client.

 If saving a few second during a compilation really improves your
 productivity you must be a really crappy programmer, which can't be
 true; you are obviously not that stupid.

Like I said above, it's all about breaking the flow.
 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.

Good point, but then you need to persuade Walter to support all that lint functionality which would be redundant if the language was sufficiently well specified. I'd rather see the effort put into closing off the corner cases, maybes and undefined functionally.

I'd be happy with just my "-ww" "warnings as warnings" patch getting accepted.
 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.

? I really don't understand your reluctance to burn cpu cycles. To me you seem to be suffering from a bad case of premature optimisation.

I'd normally be one of the first to advocate the avoidance of premature optimization, but something like duplicating all the work of a whole compiler front-end is strikes me as going a bit off the deep end. I'd compare it more to sorting large amounts of highly random data with something like a quicksort rather than a bubblesort. Besides, I don't really mean to say a D lint tool would have to avoid that duplicated parsing right from the start. It's just considering that duplication to be acceptable in the long-term that I have a problem with.
Nov 07 2009