#5746: -Werror should wait until type-checking is done
------------------------------+---------------------------------------------
Reporter: lerkok | Owner:
Type: feature request | Status: new
Priority: normal | Component: Compiler
Version: 7.2.1 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Testcase:
Blockedby: | Blocking:
Related: |
------------------------------+---------------------------------------------
I'm a big fan of "-Wall -Werror". I find that the warnings GHC generates
are well worth fixing.
With -Werror, GHC currently stops the compilation right when it detects a
warning. This does sound reasonable, but it makes for a bad user
experience. Consider:
{{{
foo :: Int -> Float
foo x = x
where c _ = 2.3
}}}
The *real* mistake here is that I should've said `c x` on the right hand
side, not just `x`. But with -Werror, GHC will first complain that `c` is
defined but not used, stopping the compilation right there, without
telling me that there's a type-error. If I go ahead and delete the
definition for 'c' to take care of the warning and compile again, I'll get
the actual type error. By then, I realize the real problem was that I
forgot to call 'c', whose definition I just deleted. Easy to fix (if
you've source control at least), but pretty bad user experience.
(Surprisingly, this scenario happens quite often in code maintenance,
definitely way more often than I'd have thought..)
A better alternative would be to *delay* the stopping effect of -Werror
until after type-checking is complete. That is,-Werror should continue
until after type-checking is completely done and thus give GHC a chance to
print type-errors, and then stop the compilation if there were any
warnings. The chances are that once the actual errors are fixed, the
warning will disappear. This'd save quite a number of edit-compile cycles,
increasing the user-experience greatly.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5746>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
