Improve deriving error messages

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.

Trac metadata

Trac field	Value
Version
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	low
Resolution	Unresolved
Component	Compiler (Type checker)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 3

added Tfeature request Trac import typechecker labels

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 CtOrigins 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?

mentioned in commit f6f82a91

mentioned in commit 4025d66c

closed

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 (closed)).

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Plow label