[GHC] #8576: Improve deriving error messages
#8576: Improve deriving error messages -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Instead of {{{ No instance for (Eq (Int -> Bool)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} for {{{ data Foo = Foo Int (Int -> Bool, Bool) deriving Eq }}} we want something like {{{ No instance for (Eq (Int -> Bool)) arising from the second field of the constructor Foo Possible fix: add an instance declaration for (Eq (Int -> Bool)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq Foo) }}} where we tell the user more precisely from where in its data type the problem comes from. Should be possible by beefing up `CtOrigin`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8576 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Theoretically possible, but would require a decent amount of code reshuffling: The `CtOrigin` is currently created in `derivTyData` (and others), and passed down to `mkEqnHelp` to `mkDataTypeEqn` to `mk_data_eqn`, where the `inferred_constraints`, which are obtained from `inferConstraints` as a list, put together with the `CtOrigin` and put into one `EarlyDerivSpec`, which does not support different `CtOrigin`s for different constraints. I do like fancy error messages, but the code (passing around plain `[Type]` for the constraint) has some elegance. Is this feature worth uprooting that? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8576#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8576: Improve deriving error messages
--------------------------------------------+------------------------------
Reporter: nomeata | Owner: nomeata
Type: feature request | Status: new
Priority: low | Milestone:
Component: Compiler (Type checker) | Version:
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Comment (by Joachim Breitner
#8576: Improve deriving error messages
--------------------------------------------+------------------------------
Reporter: nomeata | Owner: nomeata
Type: feature request | Status: new
Priority: low | Milestone:
Component: Compiler (Type checker) | Version:
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
--------------------------------------------+------------------------------
Comment (by Joachim Breitner
#8576: Improve deriving error messages --------------------------------------------+------------------------------ Reporter: nomeata | Owner: nomeata Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler (Type checker) | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: After some encouragement by SPJ, I did the refactoring, introducing `PredOrigin` and `ThetaOrigin` for constraints where we know something about where they came from. I do ''not'' use this new type in `FunDeps` yet, as suggested. Not because it is not possible (see branch `wip/T8692`), but because I could not test that code yet (see #8592). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8576#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC