1. 14 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor tcInferApps · a38acda6
      Simon Peyton Jones authored
      This is a simple refactor
      
      * Remove an unnecessary accumulating argument (acc_hs_apps) from
        the 'go' function
      
      * And put 'n' first in the same function
      a38acda6
  2. 05 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
  3. 29 Aug, 2017 3 commits
  4. 31 Jul, 2017 1 commit
  5. 29 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #14045 by omitting an unnecessary check · d1ef223c
      Richard Eisenberg authored
      Previously, we checked the number of patterns in a data instances
      for all data families whose kind did not end in a kind variable.
      But, of course, undersaturating instances can happen even without
      the kind ending in a kind variable. So I've omitted the arity check.
      Data families aren't as particular about their arity as type families
      are (because data families can be undersaturated). Still, this change
      degrades error messages when instances don't have the right arity;
      now, instead of reporting a simple mismatch in the number of patterns,
      GHC reports kind errors. The new errors are fully accurate, but perhaps
      not as easy to work with. Still, with the new flexibility of allowing
      data family instances with varying numbers of patterns, I don't see
      a better way.
      
      This commit also improves source fidelity in some error messages,
      requiring more changes than really are necessary. But without these
      changes, error messages around mismatched associated instance heads
      were poor.
      
      test cases: indexed-types/should_compile/T14045,
                  indexed-types/should_fail/T14045a
      d1ef223c
  6. 27 Jul, 2017 5 commits
    • Richard Eisenberg's avatar
      Refactor tcInferApps. · 791947db
      Richard Eisenberg authored
      With the changes caused by the fix to #12369, it is now clearer
      how to rewrite tcInferApps and friends. This should change no
      behavior, but it does clean up a nasty corner of the type checker.
      This commit also removes some uses of substTyUnchecked.
      791947db
    • Richard Eisenberg's avatar
      Fix #12369 by being more flexible with data insts · 42392383
      Richard Eisenberg authored
      Previously, a data family's kind had to end in `Type`,
      and data instances had to list all the type patterns for the
      family. However, both of these restrictions were unnecessary:
      
      - A data family's kind can usefully end in a kind variable `k`.
        See examples on #12369.
      
      - A data instance need not list all patterns, much like how a
        GADT-style data declaration need not list all type parameters,
        when a kind signature is in place. This is useful, for example,
        here:
      
          data family Sing (a :: k)
          data instance Sing :: Bool -> Type where ...
      
      This patch also improved a few error messages, as some error
      plumbing had to be moved around.
      
      See new Note [Arity of data families] in FamInstEnv for more
      info.
      
      test case: indexed-types/should_compile/T12369
      42392383
    • Richard Eisenberg's avatar
      Fix #12176 by being a bit more careful instantiating. · 1696dbf4
      Richard Eisenberg authored
      Previously, looking up a TyCon that said "no" to mightBeUnsaturated
      would then instantiate all of its invisible binders. But this is
      wrong for vanilla type synonyms, whose RHS kind might legitimately
      start with invisible binders. So a little more care is taken now,
      only to instantiate those invisible binders that need to be (so that
      the TyCon isn't unsaturated).
      1696dbf4
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
      fb752133
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
  7. 19 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13983 by creating a TyConFlavour type, and using it · 6e3c901d
      Ryan Scott authored
      An error message was referring to a type synonym as a datatype.
      Annoyingly, learning that the TyCon over which the error message is
      operating is actually a type synonym was previously impossible, since
      that code only had access to a TcTyCon, which doesn't retain any
      information about what sort of TyCon it is.
      
      To rectify this, I created a new TyConFlavour datatype, intended to
      capture roughly what sort of TyCon we're dealing with. I then performing
      the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
      propagated this information through to the relevant error message.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13983
      
      Differential Revision: https://phabricator.haskell.org/D3747
      6e3c901d
  8. 06 Jul, 2017 1 commit
  9. 03 Jul, 2017 1 commit
  10. 29 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix lexically-scoped type variables · 3b0e7555
      Simon Peyton Jones authored
      Trac #13881 showed that our handling of lexically scoped type
      variables was way off when we bring into scope a name 'y' for
      a pre-existing type variable 'a', perhaps with an entirely
      different name.
      
      This patch fixes it; see TcHsType
        Note [Pattern signature binders]
      3b0e7555
  11. 28 Jun, 2017 4 commits
  12. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
  13. 13 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Remove dead quantifyTyVars · fbb27d77
      Simon Peyton Jones authored
      This patch
      
      * removes a function TcMType.quantifyTyVars
        that was never called
      
      * renames quantifyZonkedTyVars to quantifyTyVars
      
      Plus a few comments.  No functional change at all
      fbb27d77
  14. 31 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Clean up coreView/tcView. · 6575f4b6
      Ben Gamari authored
      In Core, Constraint should be considered fully equal to
      TYPE LiftedRep, in all ways. Accordingly, coreView should
      unwrap Constraint to become TYPE LiftedRep. Of course, this
      would be a disaster in the type checker.
      
      So, where previously we used coreView in both the type checker
      and in Core, we now have coreView and tcView, which differ only
      in their treatment of Constraint.
      
      Historical note: once upon a past, we had tcView distinct from
      coreView. Back then, it was because newtypes were unwrapped in
      Core but not in the type checker. The distinction is back, but
      for a different reason than before.
      
      This had a few knock-on effects:
      
       * The Typeable solver must explicitly handle Constraint to ensure
         that we produce the correct evidence.
      
       * TypeMap now respects the Constraint/Type distinction
      
      Finished by: bgamari
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3316
      6575f4b6
  15. 27 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Simplify the logic for tc_hs_sig_type · 1e06d8b8
      Simon Peyton Jones authored
      In fixing Trac #13337, and introducing solveSomeEqualities,
      Richard introduce the higher-order function tc_hs_sig_type_x,
      with a solver as its argument.
      
      It turned out that there was a much simpler way to do the
      same thing, which this patch implements.  Less code, easier
      to grok.  No change in behaviour though.
      1e06d8b8
  16. 24 Mar, 2017 1 commit
  17. 17 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Remove solveSomeEqualities · 3cfee57a
      Richard Eisenberg authored
      I had thought that it was necessary to solve kind-level equalities
      before validity-checking a type, but I was wrong. This patch simply
      deletes code. Hooray!
      3cfee57a
  18. 14 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13337. · e0c433c8
      Richard Eisenberg authored
      The big change is the introduction of solveSomeEqualities. This
      is just like solveEqualities, but it doesn't fail if there are unsolved
      equalities when it's all done. Anything unsolved is re-emitted. This
      is appropriate if we are not kind-generalizing, so this new form
      is used when decideKindGeneralizationPlan says not to.
      
      We initially thought that any use of solveEqualities would be tied
      to kind generalization, but this isn't true. For example, we need
      to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which
      is really desugaring). These equalities are all surely going to be
      soluble (if they weren't the "kc" pass would fail), but we still
      need to solve them again. Perhaps if the "kc" pass produced type-
      checked output that is then desugared, solveEqualities really would
      be tied only to kind generalization.
      
      Updates haddock submodule.
      
      Test Plan: ./validate, typecheck/should_compile/T13337
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3315
      e0c433c8
  19. 06 Mar, 2017 1 commit
  20. 13 Feb, 2017 1 commit
  21. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  22. 18 Jan, 2017 1 commit
  23. 10 Jan, 2017 1 commit
  24. 06 Jan, 2017 1 commit
  25. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382
  26. 29 Nov, 2016 1 commit
  27. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Use TyVars in PatSyns · 12eff239
      Simon Peyton Jones authored
      I found that some TcTyVars were lurking in a PatSyn, because
      tc_patsyn_finish was using the TcType -> TcType zonker rather
      than the TcType -> Type zonker.  Eeek.
      
      I fixing this I also tided up function naming a bit (still not
      terrific), and removed the unused TcTyBinder type entirely.
      12eff239
  28. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      
      Test Plan: Validate
      
      Reviewers: goldfire, austin
      
      Subscribers: goldfire, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2528
      
      GHC Trac Issues: #11660
      6c0f10fa
  29. 04 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Remove a debug trace · 7b0ae417
      Simon Peyton Jones authored
      I added this when debugging something else, but in general it doesn't
      work (with -ddump-tc-trace) because of typecking recursive groups of
      TyCons.  So removing it again.
      7b0ae417
  30. 02 Nov, 2016 2 commits
    • Simon Peyton Jones's avatar
      Simplify the API for TcHsType.kcHsTyVarBndrs · 7a509660
      Simon Peyton Jones authored
      Pass in a Bool rather than return a funcion!
      
      No change in behaviour.
      7a509660
    • Simon Peyton Jones's avatar
      Get rid of TcTyVars more assiduously · 99689492
      Simon Peyton Jones authored
      * I found a bug in 'generalize' in TcTyClsDecls.kcTyClGroup, where
        the kind variables weren't being turned into proper TyVars, so
        we got (skolem) TcTyVars in TyCons, which shouldn't happen.  Fix
        was easy.
      
      * Similarly TcHsType.kindGeneralizeType wasn't turning the forall'd
        TcTyVars into TyVars.  To achieve this I defined TcHsTyn.zonkSigType.
      
      * All this allowed me to remove awkward and ill-explained bit of
        footwork on DFunIds in Inst.newClsInst
      
      This is just refactoring, but it does make the printout from
      -ddump-deriv make a bit more sense by not grautuitiously cloning
      type variables.  In the display I was seeing
      
         instance C [a_df4] where
            f x = ...a_dx5...
      
      where actually the d_df4 and a_dx5 were the same.
      99689492