www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10147] New: Make -w identical to -wi and deprecate it

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147

           Summary: Make -w identical to -wi and deprecate it
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg gmx.com> 2013-05-23 03:54:53
PDT ---
-w is inherently broken, because it changes the semantics of code when static
inference and conditional compilation and whatnot are involved. -wi is by far
the smarter approach, and I really don't think that -w should have existed in
the first place. But given that we have it (and it predates -wi), removing it
at this point would break a lot of projects.

So, I propose that we simply make it so that -w does the same thing as -wi and
deprecate it. It's at least _possible_ that some code will break due to the
change in semantics, but it's that change in semantics that we want to
eliminate, and for the most part, code breakage is unlikely (and arguably would
be desirable given the semantics changes of using -w). So, with -w deprecated,
projects can migrate to using -wi, which won't change their code's semantics,
and we can possibly remove -w at some point in the future (or just remove it
from the docs if we don't want to go the extra step of removing it).

In any case, I think that we would be far better of with -w and that we should
at least seriously consider getting rid of it, and making it the same as -wi
seems like a good step in that direction to me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com


--- Comment #1 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-05-23
19:12:16 PDT ---
 -w is inherently broken, because it changes the semantics of code when static
inference and conditional compilation and whatnot are involved. Can you please be more specific, maybe with example code? I have no knowledge of any of this.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #2 from Jonathan M Davis <jmdavisProg gmx.com> 2013-05-23 19:27:40
PDT ---
 Can you please be more specific, maybe with example code? I have no knowledge
 of any of this.
Okay. Let's say that you have a function like auto foo(T)(T t) { switch(t.val) { case 1: writeln("warnings"); case 2: writeln("become"); case 3: writeln("errors"); default: break; } return t.ret; } Without -w, this code will compile just fine (assuming that T has a member called val which works with a switch statement as well as a member called ret). But with -w, it won't compile thanks to the fact that it uses implicit fallthrough. Now, say you have a function like auto bar(T)(T t) if(is(typeof(foo(T.init)))) { ... } The template constraint passes if the argument compiles with foo and fails if it doesn't. So, without -w, if you have the type struct S { int val; int ret; } and you pass it to bar, the code will compile. But if you compile with -w, it won't, because foo no longer compiles thanks to implicit fallthrough becoming an error. _Anything_ that tests whether code compiles potentially breaks thanks to -w. How big a problem this is in practice, I don't know, but -w can change the semantics of code, meaning that whether you compile with -w or not effectively creates two different languages. Normally, we reject any suggestions that involve flags like this. -w really makes no sense. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-05-24
05:29:43 PDT ---
That seems like a problem with lack of testing from the developer. 

GCC has similar features like -pedantic-errors and -Werror=
(http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Warning-Options.html).

I'd hate to have to manually abort the compiler process on the first warning
message.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #4 from Jonathan M Davis <jmdavisProg gmx.com> 2013-05-24 10:05:44
PDT ---
 That seems like a problem with lack of testing from the developer. 
In this case, yes, but there may be cases where that's not true. But if even there aren't, it means that we have a flag which changes what's legal in the language and therefore potentially changes the semantics of code, which risks bugs without good reason IMHO.
 GCC has similar features like -pedantic-errors and -Werror=
 (http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Warning-Options.html).
C++ doesn't have the compile time introspection capabilities that D has, so it wouldn't have as many issues with it. If it's really only a matter of make it so that no object code is generated when I have have warnings, then that wouldn't be a big deal, but in D, it actually affects the semantics of the program. And it wouldn't even necessarily change them in a way that causes the program to not compile. It could be that it would result in simply taking the wrong/inefficient overload without the programmer knowing. e.g. auto foo(T)(T t) if(isBar!T) {...} auto foo(T)(T t) if(!isBar!T) {...}
 I'd hate to have to manually abort the compiler process on the first warning
 message.
I don't follow. Why would anything have to be manually aborted? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #5 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-05-24
11:03:45 PDT ---
(In reply to comment #4)
 I don't follow. Why would anything have to be manually aborted?
Well if -w no longer aborts compilation on the first warning, it means the compiler will continue compiling. So if it takes 10 seconds to compile something I have to manually kill the compiler process on the first warning if I want to save some time. Also, what if I *want* compilation to fail on e.g. switch fallthrough? Actually I don't even know why that is a warning instead of an error, who wants bugs in their code? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #6 from Jonathan M Davis <jmdavisProg gmx.com> 2013-05-24 11:18:35
PDT ---
Oh, I'd love to get rid of both -w and -wi and just make everything a warning
or nothing, but I don't expect that to happen at this point. Switch fallthrough
might become a full error at some point though.

Another alternative would be to make it so that -w stops compilation like it
would with an error, but it has no effect on compile-time introspection or any
other semantics. I don't know how easy it would be to do that in the compiler
though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #7 from bearophile_hugs eml.cc 2013-06-29 16:31:43 PDT ---
*** Issue 10321 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #8 from bearophile_hugs eml.cc 2013-06-29 16:38:45 PDT ---
I have closed down my Issue 10321 because despite it's not exactly a
duplicated, I think it's better to aggregate them.

Summarizing, the needs and problems are:
- You have explained well why the "-w" warning is bad.
- Lot of people don't see the warnings switch of the compiler, so they don't
see the warnings, and this makes their programs worse or they don't understand
some other errors that are generated later. So I believe the informational
warnings should be active on default (and the compiler should have a switch to
disable them in the rare cases when you don't want them).
- On the other hand Andrej Mitrovic (and probably others, now or in future)
want a switch like in GCC that halts the compilation at the first warning. I
think this is not a common need, but it exists. I don't know how to make this
work considering the problems of the "-w" switch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #9 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-06-29
17:28:14 PDT ---
(In reply to comment #8)
 - On the other hand Andrej Mitrovic (and probably others, now or in future)
 want a switch like in GCC that halts the compilation at the first warning. I
 think this is not a common need, but it exists. I don't know how to make this
 work considering the problems of the "-w" switch.
Hmm thinking about this some more I think the only reason I've ever needed -w was because of issues like missing default switch and switch case fall-through (and perhaps missing override keyword), which IIRC used to be warnings but are now finally deprecated behavior. Some warnings in DMD should have been errors from the get-go. I don't think many (if any?) warnings are left that should be errors, and this was the only reason why I needed -w. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #10 from bearophile_hugs eml.cc 2013-06-29 17:34:16 PDT ---
(In reply to comment #9)

 Hmm thinking about this some more I think the only reason I've ever needed -w
 was because of issues like missing default switch and switch case fall-through
 (and perhaps missing override keyword), which IIRC used to be warnings but are
 now finally deprecated behavior.
 
 Some warnings in DMD should have been errors from the get-go. I don't think
 many (if any?) warnings are left that should be errors, and this was the only
 reason why I needed -w.
Some new warnings (and later deprecations) will be added because there are more than one thousand issues open and some of them are about small D design mistakes that I really hope will eventually be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com


--- Comment #11 from monarchdodra gmail.com 2013-06-30 00:11:18 PDT ---
(In reply to comment #2)
 Can you please be more specific, maybe with example code? I have no knowledge
 of any of this.
Okay. Let's say that you have a function like [...] _Anything_ that tests whether code compiles potentially breaks thanks to -w. How big a problem this is in practice, I don't know, but -w can change the semantics of code, meaning that whether you compile with -w or not effectively creates two different languages. Normally, we reject any suggestions that involve flags like this. -w really makes no sense.
Couldn't we instead "fix" "-w" ? Currently, it transforms any warning into an error, creating the above mentioned problem. What we *really* want (as stated by Andrej) is simply for compilation to halt on the first reported warning. If we simply "upgrade" -w to work as in "if a warning is *emitted*, then translate that warning into an error, and then halt compilation. This means we'd have 100% the same behavior between "", "-w", "-wi", but still get the behavior of "I refuse to compile until you process this warning". I'm not compiler savvy, so wouldn't know how easy it is to improve it to do this, but it seems better than to simply deprecate it... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147


Dicebot <m.strashun gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.strashun gmail.com


--- Comment #12 from Dicebot <m.strashun gmail.com> 2013-06-30 00:57:51 PDT ---
I consider the very existence of warnings a mistake. Their use cases are
completely taken over by static analysis tools. I think the idea solution would
have been to go through the list of warnings and make some of them errors.
Remaining ones should stay available only as -wi and once standard static
analysis tool will appear - completely moved there.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10147



--- Comment #13 from Jonathan M Davis <jmdavisProg gmx.com> 2013-06-30 03:27:18
PDT ---
I would _love_ it if we got rid of warnings completely, and I know that Walter
has similar feelings. I believe that we have them primarily because Walter got
bullied into it, and that's likely why dmd has such abnormal behavior with
regards to warnings. What every other compiler I've ever used does is _always_
emit warnings, and if there's a flag for making them errors, it's not normally
used.

Warnings are horrible, because they aren't things that are necessarily actually
wrong, and yet you're then forced to fix them, because it's bad practice (and
hides legitimate problems) if you leave a bunch of warnings in your code. So,
ultimately, there's not much difference between an error and a warning. We'd be
_far_ better off without them. I completely agree with Dicebot that anything
which is not _guaranteed_ to be wrong should be done with a static analysis
tool.

That being said, if we're stuck with -w and/or -wi, -w needs to fixed - either
by fixing its behavior so that it has no effect on conditional compilation or
by getting rid of it in favor of just having -wi.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2013