Skip to content
Snippets Groups Projects
Commit f0decae7 authored by Simon Peyton Jones's avatar Simon Peyton Jones
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 73d07c6e
No related branches found
No related tags found
1 merge request!10083Be more careful about quantification
Pipeline #64612 passed
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