Skip to content
Snippets Groups Projects
Forked from Glasgow Haskell Compiler / GHC
Source project has a limited visibility.
  • Simon Peyton Jones's avatar
    8b9b7dbc
    Use the eager unifier in the constraint solver · 8b9b7dbc
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    This patch continues the refactoring of the constraint solver
    described in #23070.
    
    The Big Deal in this patch is to call the regular, eager unifier from the
    constraint solver, when we want to create new equalities. This
    replaces the existing, unifyWanted which amounted to
    yet-another-unifier, so it reduces duplication of a rather subtle
    piece of technology. See
    
      * Note [The eager unifier] in GHC.Tc.Utils.Unify
      * GHC.Tc.Solver.Monad.wrapUnifierTcS
    
    I did lots of other refactoring along the way
    
    * I simplified the treatment of right hand sides that contain CoercionHoles.
      Now, a constraint that contains a hetero-kind CoercionHole is non-canonical,
      and cannot be used for rewriting or unification alike.  This required me
      to add the ch_hertero_kind flag to CoercionHole, with consequent knock-on
      effects. See wrinkle (2) of `Note [Equalities with incompatible kinds]` in
      GHC.Tc.Solver.Equality.
    
    * I refactored the StopOrContinue type to add StartAgain, so that after a
      fundep improvement (for example) we can simply start the pipeline again.
    
    * I got rid of the unpleasant (and inefficient) rewriterSetFromType/Co functions.
      With Richard I concluded that they are never needed.
    
    * I discovered Wrinkle (W1) in Note [Wanteds rewrite Wanteds] in
      GHC.Tc.Types.Constraint, and therefore now prioritise non-rewritten equalities.
    
    Quite a few error messages change, I think always for the better.
    
    Compiler runtime stays about the same, with one outlier: a 17% improvement in T17836
    
    Metric Decrease:
        T17836
        T18223
    8b9b7dbc
    History
    Use the eager unifier in the constraint solver
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    This patch continues the refactoring of the constraint solver
    described in #23070.
    
    The Big Deal in this patch is to call the regular, eager unifier from the
    constraint solver, when we want to create new equalities. This
    replaces the existing, unifyWanted which amounted to
    yet-another-unifier, so it reduces duplication of a rather subtle
    piece of technology. See
    
      * Note [The eager unifier] in GHC.Tc.Utils.Unify
      * GHC.Tc.Solver.Monad.wrapUnifierTcS
    
    I did lots of other refactoring along the way
    
    * I simplified the treatment of right hand sides that contain CoercionHoles.
      Now, a constraint that contains a hetero-kind CoercionHole is non-canonical,
      and cannot be used for rewriting or unification alike.  This required me
      to add the ch_hertero_kind flag to CoercionHole, with consequent knock-on
      effects. See wrinkle (2) of `Note [Equalities with incompatible kinds]` in
      GHC.Tc.Solver.Equality.
    
    * I refactored the StopOrContinue type to add StartAgain, so that after a
      fundep improvement (for example) we can simply start the pipeline again.
    
    * I got rid of the unpleasant (and inefficient) rewriterSetFromType/Co functions.
      With Richard I concluded that they are never needed.
    
    * I discovered Wrinkle (W1) in Note [Wanteds rewrite Wanteds] in
      GHC.Tc.Types.Constraint, and therefore now prioritise non-rewritten equalities.
    
    Quite a few error messages change, I think always for the better.
    
    Compiler runtime stays about the same, with one outlier: a 17% improvement in T17836
    
    Metric Decrease:
        T17836
        T18223
Code owners
Assign users and groups as approvers for specific file changes. Learn more.