Skip to content
  • Ryan Scott's avatar
    Clean up the inferred type variable restriction · 01c948eb
    Ryan Scott authored and Marge Bot's avatar Marge Bot committed
    This patch primarily:
    
    * Documents `checkInferredVars` (previously called
      `check_inferred_vars`) more carefully. This is the
      function which throws an error message if a user quantifies an
      inferred type variable in a place where specificity cannot be
      observed. See `Note [Unobservably inferred type variables]` in
      `GHC.Rename.HsType`.
    
      Note that I now invoke `checkInferredVars` _alongside_
      `rnHsSigType`, `rnHsWcSigType`, etc. rather than doing so _inside_
      of these functions. This results in slightly more call sites for
      `checkInferredVars`, but it makes it much easier to enumerate the
      spots where the inferred type variable restriction comes into
      effect.
    * Removes the inferred type variable restriction for default method
      type signatures, per the discussion in #18432. As a result, this
      patch fixes #18432.
    
    Along the way, I performed some various cleanup:
    
    * I moved `no_nested_foralls_contexts_err` into `GHC.Rename.Utils`
      (under the new name `noNestedForallsContextsErr`), since it now
      needs to be invoked from multiple modules. I also added a helper
      function `addNoNestedForallsContextsErr` that throws the error
      message after producing it, as this is a common idiom.
    * In order to ensure that users cannot sneak inferred type variables
      into `SPECIALISE instance` pragmas by way of nested `forall`s, I
      now invoke `addNoNestedForallsContextsErr` when renaming
      `SPECIALISE instance` pragmas, much like when we rename normal
      instance declarations. (This probably should have originally been
      done as a part of the fix for #18240, but this task was somehow
      overlooked.) As a result, this patch fixes #18455 as a side effect.
    01c948eb