[GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors.

[GHC]

#15539: Regression since 7.10.3, "variable not in scope" errors sometimes get
buried under a sea of much less relevant errors.
-------------------------------------+-------------------------------------
           Reporter:  Wizek          |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.4.3
           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:
-------------------------------------+-------------------------------------
 Me and Neil Mitchell have ran into this quite a few times while using
 GHCid, here is our discussion:

 https://github.com/ndmitchell/ghcid/issues/159

 Here is a small reproducible example:

 {{{#!hs
 module Main where

 foo :: String
 foo = show a
   where a = baz

 bar :: Int
 bar = 1

 main = putStrLn foo
 }}}

 GHC 8.0.x and above will say

 {{{
 src/Main.hs:4:7: error:
     • Ambiguous type variable ‘a0’ arising from a use of ‘show’
       prevents the constraint ‘(Show a0)’ from being solved.
       Probable fix: use a type annotation to specify what ‘a0’ should be.
       These potential instances exist:
         instance (Show a, Show b) => Show (Either a b)
           -- Defined in ‘Data.Either’
         instance Show Ordering -- Defined in ‘GHC.Show’
         instance Show Integer -- Defined in ‘GHC.Show’
         ...plus 23 others
         ...plus 212 instances involving out-of-scope types
         (use -fprint-potential-instances to see them all)
     • In the expression: show a
       In an equation for ‘foo’:
           foo
             = show a
             where
                 a = baz
   |
 4 | foo = show a
   |       ^^^^^^
 src/Main.hs:5:13: error:
     • Variable not in scope: baz
     • Perhaps you meant ‘bar’ (line 8)
   |
 5 |   where a = baz
   |             ^^^
 }}}

 It's much more useful and much less noisy what 7.10.3 reports:

 {{{
 src/Main.hs:5:13:
     Not in scope: ‘baz’
     Perhaps you meant ‘bar’ (line 8)
 }}}

 So a desired output would be something like this for a later GHC release:

 {{{
 src/Main.hs:5:13: error:
     • Variable not in scope: baz
     • Perhaps you meant ‘bar’ (line 8)
   |
 5 |   where a = baz
   |             ^^^
 }}}

 Or if someone is adamant about keeping the other errors even when there
 are out of scope variables present, then at least can we please reorder
 them such that the much more relevant out-of-scope errors are at the top?

 {{{
 src/Main.hs:5:13: error:
     • Variable not in scope: baz
     • Perhaps you meant ‘bar’ (line 8)
   |
 5 |   where a = baz
   |             ^^^
 src/Main.hs:4:7: error:
     • Ambiguous type variable ‘a0’ arising from a use of ‘show’
       prevents the constraint ‘(Show a0)’ from being solved.
       Probable fix: use a type annotation to specify what ‘a0’ should be.
       These potential instances exist:
         instance (Show a, Show b) => Show (Either a b)
           -- Defined in ‘Data.Either’
         instance Show Ordering -- Defined in ‘GHC.Show’
         instance Show Integer -- Defined in ‘GHC.Show’
         ...plus 23 others
         ...plus 212 instances involving out-of-scope types
         (use -fprint-potential-instances to see them all)
     • In the expression: show a
       In an equation for ‘foo’:
           foo
             = show a
             where
                 a = baz
   |
 4 | foo = show a
   |       ^^^^^^
 }}}

 I might even be up for fixing this if there is agreement on the next steps
 to be taken. (Though I've never contributed to GHC before, on the surface
 this doesn't seem hard to fix.)

 What do you think?

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