Opened 5 months ago

Closed 5 months ago

#8576 closed feature request (fixed)

Improve deriving error messages

Reported by: nomeata Owned by: nomeata
Priority: low Milestone:
Component: Compiler (Type checker) Version:
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Change History (4)

comment:1 Changed 5 months ago 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 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?

comment:2 Changed 5 months ago by Joachim Breitner <mail@…>

In 4025d66cc795b728f745aec23fc5c2267d1839f0/ghc:

Elaborate "deriving" error messages

If "deriving (C)" fails, it will now, if possible, indicate which
particular field of which constructor has caused the failure. (This
fixes #8576)

comment:3 Changed 5 months ago by Joachim Breitner <mail@…>

In b3b88db924f39d83586f41cf35608bc4809b2a9a/testsuite:

Update output: New error messages as per #8576

comment:4 Changed 5 months ago by nomeata

  • Resolution set to fixed
  • Status changed from new to 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).

Note: See TracTickets for help on using tickets.