#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