Skip to content
Snippets Groups Projects
Commit 926ad6de authored by Simon Peyton Jones's avatar Simon Peyton Jones Committed by Marge Bot
Browse files

Be more careful about quantification

This MR is driven by #23051. It does several things:

* It is guided by the generalisation plan described in #20686.
  But it is still far from a complete implementation of that plan.

* Add Note [Inferred type with escaping kind] to GHC.Tc.Gen.Bind.
  This explains that we don't (yet, pending #20686) directly
  prevent generalising over escaping kinds.

* In `GHC.Tc.Utils.TcMType.defaultTyVar` we default RuntimeRep
  and Multiplicity variables, beause we don't want to quantify over
  them.  We want to do the same for a Concrete tyvar, but there is
  nothing sensible to default it to (unless it has kind RuntimeRep,
  in which case it'll be caught by an earlier case). So we promote
  instead.

* Pure refactoring in GHC.Tc.Solver:
  * Rename decideMonoTyVars to decidePromotedTyVars, since that's
    what it does.

  * Move the actual promotion of the tyvars-to-promote from
    `defaultTyVarsAndSimplify` to `decidePromotedTyVars`.  This is a
    no-op; just tidies up the code.  E.g then we don't need to
    return the promoted tyvars from `decidePromotedTyVars`.

  * A little refactoring in `defaultTyVarsAndSimplify`, but no
    change in behaviour.

* When making a TauTv unification variable into a ConcreteTv
  (in GHC.Tc.Utils.Concrete.makeTypeConcrete), preserve the occ-name
  of the type variable.  This just improves error messages.

* Kill off dead code: GHC.Tc.Utils.TcMType.newConcreteHole
parent ea24360d
No related branches found
No related tags found
No related merge requests found
Showing
with 242 additions and 187 deletions
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment