Re: #16404: Type error recovery crash

--===============5150375054888727441==
Content-Type: multipart/related;
 boundary="===============4202798300409705924=="

--===============4202798300409705924==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

#16404: Type error recovery crash
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Reason for this: this code in `TcBinds`
 {{{
 tcPolyBinds sig_fn prag_fn rec_group rec_tc closed bind_list
   = setSrcSpan loc                              $
     recoverM (recoveryCode binder_names sig_fn) $ do
         -- Set up main recover; take advantage of any type sigs
 }}}
 recovers from an error in the binding for `f`.  But the recovery code is:
 {{{
 recoveryCode :: [Name] -> TcSigFun -> TcM (LHsBinds GhcTcId, [Id])
 recoveryCode binder_names sig_fn
   = do  { traceTc "tcBindsWithSigs: error recovery" (ppr binder_names)
         ; let poly_ids = map mk_dummy binder_names
         ; return (emptyBag, poly_ids) }
 }}}
 That is, it returns no bindings.  That's probably wrong if we have
 `-fdefer-type-errors`.  We should probably generate a stub binding
 {{{
   f = typeError "Deferred error in binding for f"
 }}}
 That would avoid downstream breakage.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16404#comment:1>