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


 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.


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 

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.


begin 666 dlint.bat

M<F=S+ T*4D5-(&)U="!T:&%T(&-A;B!B92!F:7AE9"!I;B!V, T*0&5C:&\ 

`
end
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 

 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

 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