[GHC] #7010: Type error in one function causes wrong type error report in another function when using type families

[GHC]

#7010: Type error in one function causes wrong type error report in another
function when using type families
-----------------------------------------------+----------------------------
 Reporter:  Lemming                            |          Owner:                  
     Type:  bug                                |         Status:  new             
 Priority:  normal                             |      Component:  Compiler        
  Version:  7.4.1                              |       Keywords:                  
       Os:  Unknown/Multiple                   |   Architecture:  Unknown/Multiple
  Failure:  Incorrect warning at compile-time  |       Testcase:                  
Blockedby:                                     |       Blocking:                  
  Related:                                     |  
-----------------------------------------------+----------------------------
 This ticket is very similar to #5978, but this time it is about type
 families. If I load the attached module I get the two error messages:
 {{{
 TypeCheck7_4_1_TF_IncorrectMsg.hs:27:21:
     Couldn't match type `Float' with `Serial Float'
     Expected type: (ValueTuple Vector, ValueTuple Vector)
       Actual type: (Serial Float, Serial Float)
     In the first argument of `processIO', namely `stereoFromMono'
     In the expression: processIO stereoFromMono

 TypeCheck7_4_1_TF_IncorrectMsg.hs:42:27:
     Couldn't match type `IO' with `Serial'
     Expected type: (Float, ValueTuple Vector)
       Actual type: (Float, ValueTuple Float)
     In the first argument of `withArgs', namely `plug'
     In the expression: withArgs plug
 }}}
 If I uncomment 'filterFormant', that is, only the second one of the two
 criticized parts, then the module is accepted.

 These two error messages are very confusing because in the original module
 'phoneme' was a complex definition and it was not immediately clear that
 it is actually correct. Trying hard to fix it does not succeed because it
 is not broken.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7010>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler