[GHC] #11014: re-order GHC type errors for clarity

[GHC]

#11014: re-order GHC type errors for clarity
-------------------------------------+-------------------------------------
        Reporter:  elaforge          |                Owner:  elaforge
            Type:  feature request   |               Status:  closed
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.11
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect         |  Unknown/Multiple
  warning at compile-time            |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1427
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Evan, thank you for doing this. I think it's a step forward.

 I failed to review your patch in a timely way, but I've now had a quick
 look.  Some questions

 * The Monoid instance of `Report` is suspicious. Do you ''really'' merge
 two separate reports, combining their important and relevant-bindings
 stuff?  Of course not!  Rather, you use it exclusively to combine a
 degenerate report with only 'important' stuff and another degenerate
 report with only 'supplementary' stuff.

   This seems confusing and indirect. Instead of
 {{{
 let report = important given_msg `mappend` relevant_bindings binds_msg
 }}}
   why not say
 {{{
 let report = mkReport given_msg binds_msg
 }}}
   and drop the suspicious Monoid instance.

 * It will not have escaped your attention that `TcErrors.Report` and
 `ErrUtils.ErrDoc` are virtually identical. Could you perhaps just combine
 them?  To get the `errDocContext` you could either (I suppose) start with
 it empty, and add it; or make `mkReport` monadic (better probably).

 * I'd love you to do as you suggest and get rid of `errMsgShortString`.

 * Are you sure you need to filter out empty docs?  Can't you just avoid
 putting empty docs into the [SDoc] in the first place?

 Thanks!

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11014#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler