Error with Generic constraint on type\data family GHC 9.4.2

[Diamondy4]

generics-sop seems to be broken when Generic constraint used with data or type family on ghc 9.4.2

Minimal failing example:
The following typechecks on ghc <= 9.2

import qualified GHC.Generics as GHC
import Generics.SOP

data MyType a = MyType
  { field1 :: Int
  , field2 :: String
  }
  deriving (GHC.Generic)
  deriving anyclass (Generic)

data family MyDataFamilyType a

type family MyTypeFamilyType a

tstT :: Generic (MyType a) => ()
tstT = ()

tstDF :: Generic (MyDataFamilyType a) => ()
tstDF = ()

tstTF :: Generic (MyTypeFamilyType a) => ()
tstTF = ()

but fails to typecheck on 9.4.2 with error

• solveWanteds: too many iterations (limit = 4)
    Unsolved: WC {wc_simple =
                    [W] irred_aeIP {0}:: Data.SOP.Constraint.AllF
                                           SListI (Code (MyDataFamilyType a0)) (CIrredCan(irred))
                    [W] irred_aeIV {0}:: Data.SOP.Constraint.AllF
                                           Top (Code (MyDataFamilyType a0)) (CIrredCan(irred))
                    [W] $dGeneric_aeIG {0}:: Generic (MyDataFamilyType a0) (CDictCan)
                    [W] $dAll_aeIO {0}:: All
                                           SListI (Code (MyDataFamilyType a0)) (CDictCan)
                    [W] $dAll_aeIW {0}:: All
                                           Top (Code (MyDataFamilyType a0)) (CDictCan(psc))}
    Simples: {[W] irred_aeIP {0}:: Data.SOP.Constraint.AllF
                                     SListI (Code (MyDataFamilyType a0)) (CIrredCan(irred)),
              [W] irred_aeIV {0}:: Data.SOP.Constraint.AllF
                                     Top (Code (MyDataFamilyType a0)) (CIrredCan(irred)),
              [W] $dGeneric_aeIG {0}:: Generic (MyDataFamilyType a0) (CDictCan),
              [W] $dAll_aeIO {0}:: All
                                     SListI (Code (MyDataFamilyType a0)) (CDictCan),
              [W] $dAll_aeIW {0}:: All
                                     Top (Code (MyDataFamilyType a0)) (CDictCan(psc))}
• In the type signature:
    tstDF :: forall a. Generic (MyDataFamilyType a) => ()
• Set limit with -fconstraint-solver-iterations=n; n=0 for no limit

-fconstraint-solver-iterations does nothing here on n >= 0, and fails with OOM error on n = 0

[kosmikus]

Hi. Thanks for bringing this to my attention. I'll try to reproduce as soon as possible. Most likely, though, this should be reported as a GHC bug, because it's a regression in GHC (unless it somehow turns out that previously accepting this code was the buggy behaviour, but I doubt it). Would you want to do this, or would you prefer if I do?

[Diamondy4]

I think it could be connected to 9.4 changes, namely:

There were previously cases around functional dependencies and injective type families where the result of type inference would depend on the order of constraints, as written in a source file. These cases are fundamentally ambiguous. While GHC previously made an arbitrary decision, it now notices the ambiguity and rejects the program. This means that some previously accepted programs are now rejected. The solution is to add a type annotation or type application to resolve the ambiguity.

This is the fix for [#18851](https://gitlab.haskell.org/ghc/ghc/issues/18851).

or

Due to various changes in the typechecker’s constraint solver, some programs may need additional constraints to be explicitly provided. See the [Migration guide](https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4#inference-for-simplifiable-constraints) for details.

I'll report it as bug though.

[locallycompact]

Can you post a link to the ghc bug report?

[RyanGlScott]

I've minimized the example and reported upstream as GHC#22516.

[Diamondy4]

I've minimized the example and reported upstream as GHC#22516.

Was very busy and forgot about reporting this bug to GHC. Thanks!

[ysangkok]

Is this issue fixed in GHC 9.4.5 as this commit suggests (click the three branch dots)?

[RyanGlScott]

I've confirmed that this is the case (after adding the appropriate language extensions to the top of the file).