[GHC] #14106: Out of scope errors appear after type errors caused by them

#14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example: import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print .~ is out of scope, the error output: ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed. In larger examples, the out of scope error can be buried deep down. In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that. Out of scope errors should be put BEFORE any type errors that might be caused by them. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14106 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description:
Example:
import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print
.~ is out of scope, the error output:
ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed.
In larger examples, the out of scope error can be buried deep down.
In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that.
Out of scope errors should be put BEFORE any type errors that might be caused by them.
New description: Example: {{{ import Control.Lens (_Just, (&)) main = Just 5 & _Just .~ 100 & print }}} .~ is out of scope, the error output: {{{ ghc-error.hs:2:17-21: error: … • Couldn't match type ‘Maybe’ with ‘p0 a0’ Expected type: Maybe (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) Actual type: p0 a0 (f0 b0) -> p0 (Maybe a0) (f0 (Maybe b0)) • In the second argument of ‘(&)’, namely ‘_Just’ In the first argument of ‘(.~)’, namely ‘Just 5 & _Just’ In the expression: (.~) Just 5 & _Just 100 & print ghc-error.hs:2:23-24: error: … • Variable not in scope: (.~) :: p0 (Maybe a0) (f0 (Maybe b0)) -> IO () -> t • Perhaps you meant ‘.’ (imported from Prelude) Perhaps you want to add ‘.~’ to the import list in the import of ‘Control.Lens’ (/home/eyal/devel/test/ghc-error.hs:1:1-32). Compilation failed. }}} In larger examples, the out of scope error can be buried deep down. In the case of operators - the fixity is unknown so it can even cause the parse to go wrong - and very weird type errors to result from that. Out of scope errors should be put BEFORE any type errors that might be caused by them. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14106#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14106: Out of scope errors appear after type errors caused by them -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I do rather agree. Currently, GHC * Suppresses warnings if there are any errors * Sorts errors/warnings by line number Better, I think, would be * Sort all messages by severity, most severe first * Then, within severity, by line number * Ensure that out-of-scope errors are somehow more severe There are hooks for all this: all messages have a line number and a severity. But it's not terribly well structured or described, so it might take a bit of careful work to implement this ideas. Nothing actually difficult, though. Volunteers? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14106#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC