[GHC] #12157: Warning priorities (or: report hole warnings first)

[GHC]

#12157: Warning priorities (or: report hole warnings first)
-------------------------------------+-------------------------------------
           Reporter:  ertes          |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 In a typical development workflow some warnings are more useful/urgent
 /short-term than others:

 {{{#!hs
 {-# OPTIONS_GHC -W -fdefer-typed-holes #-}

 myFunction x y =
     x + _someFunc x + _
 }}}

 In this example there are three warnings: two holes and one unused
 variable.  Currently they are reported in the order they come up, which is
 usually not a very useful ordering.

 One would not want to disable any of them, but with editor integration in
 mind it would be very useful to move certain warnings to the top of the
 output, so that one does not have to skip countless "unused import" and
 "defined, but not used" warnings to finally reach the one hole warning one
 actually cares about.

 As a quick fix, an option to move hole warnings to the top of the output
 would already be of great help.  More generally I'd like to ask for a
 priority system for different warning types, ideally with sensible
 defaults.

 Regarding typed holes in particular it would also be useful to be able to
 annotate some holes as particularly interesting (short-term vs. long-term
 holes), so they appear first among the other hole warnings.  It would
 suffice to report `_` holes first, then perhaps the single-letter holes
 and finally the rest.  In the example above, that would mean that the `_`
 hole is reported ''before'' the `_someFunc` hole.

 Of course all of this also applies to errors. "Not in scope" errors are
 usually easy to get out of the way, so some developers may prefer to deal
 with them first, while others may prefer to deal with more interesting
 errors (like type errors) first.

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