#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