This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 17 Mar, 2017 1 commit
  2. 14 Mar, 2017 1 commit
    • Ryan Scott's avatar
      Allow associated types to pattern-match in non-class-bound variables · 67345ccf
      Ryan Scott authored
      Summary:
      After 8136a5cb (#11450), if you have
      a class with an associated type:
      
      ```
      class C a where
        type T a b
      ```
      
      And you try to create an instance of `C` like this:
      
      ```
      instance C Int where
        type T Int Char = Bool
      ```
      
      Then it is rejected, since you're trying to instantiate the variable ``b`` with
      something other than a type variable. But this restriction proves quite
      onerous in practice, as it prevents you from doing things like this:
      
      ```
      class C a where
        type T a (b :: Identity c) :: c
      
      instance C Int where
        type T Int ('Identity x) = x
      ```
      
      You have to resort to an auxiliary type family in order to define this now,
      which becomes extremely tiring. This lifts this restriction and fixes #13398,
      in which it was discovered that adding this restriction broke code in the wild.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3302
      67345ccf
  3. 10 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
  4. 04 Mar, 2017 1 commit
  5. 26 Feb, 2017 3 commits
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
    • rwbarton's avatar
      tests: manually move some extra_files into *.T files · 98119f5a
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      Some of the *.T files were in libraries/hpc, so this contains an
      update to that submodule.
      98119f5a
    • Tamar Christina's avatar
      Load dependent dlls. · 41e54b4b
      Tamar Christina authored and Ben Gamari's avatar Ben Gamari committed
      When the `GCC` driver envokes the pipeline a `SPEC` is used to determine
      how to configure the compiler and which libraries to pass along.
      
      For Windows/mingw, this specfile is
      https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h
      
      This has a lot of interesting things that we need to emulate in order to
      be able to link as many things out of the box as GCC. In particular this
      is why you never need to specify `-lgcc_s` when compiling, but you do
      when using `GHCi`.
      
      Unfortunately due to time constraints I can't set up the framework
      required in `GHC` to do this before the feature freeze.
      
      So I suggest this alternate implementation:
      When we load a dll, also bring it's dependencies into scope of the
      interpeter.
      
      This has pros and cons. Pro is, we'll fix many packages on hackage which
      specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which
      will bring `libgcc` into scope.
      
      The downside is, we'll be more lenient than GCC, in that the interpreter
      will link much easier since it has implicit dependencies in scope.
      Whereas for compilation to work you will have to specify it as an
      argument to GHC.
      
      This will make the Windows runtime linker more consistent with the unix
      ones. The difference in semantics came about because of the differences
      between `dlsym` and `GetProcAddress`.  The former seems to search the
      given library and all it's dependencies, while the latter only searches
      the export table of the library. So we need some extra manual work to
      search the dependencies which this patch provides.
      
      Test Plan:
      ```
      ./validate
      ```
      ```
      $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS
      -lstdc++ 2>&1 | grep "Loading dependency"
      ```
      
      ```
      $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS
      -Dl -RTS 2>&1 | grep "Loading dependency"
      Loading dependency *.exe -> GDI32.dll.
      Loading dependency GDI32.dll -> ntdll.dll.
      Loading dependency *.exe -> KERNEL32.dll.
      Loading dependency KERNEL32.dll -> KERNELBASE.dll.
      Loading dependency *.exe -> msvcrt.dll.
      Loading dependency *.exe -> SHELL32.dll.
      Loading dependency SHELL32.dll -> USER32.dll.
      Loading dependency USER32.dll -> win32u.dll.
      Loading dependency *.exe -> WINMM.dll.
      Loading dependency WINMM.dll -> WINMMBASE.dll.
      Loading dependency *.exe -> WSOCK32.dll.
      Loading dependency WSOCK32.dll -> WS2_32.dll.
      Loading dependency WS2_32.dll -> RPCRT4.dll.
      Loading dependency libstdc++-6.dll -> libwinpthread-1.dll.
      Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll.
      ```
      
      Trac tickets: #13093, #13189
      
      Reviewers: simonmar, rwbarton, austin, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D3028
      41e54b4b
  6. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      
      This involves a few things,
      
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         of `(->)` with the appropriate `RuntimeRep` arguments
      
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      
      Also, this introduces two known regressions,
      
      `tcfail181`, `T10403`
      =====================
      Only shows the instance,
      
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      
      T5963 (Typeable)
      ================
      
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      
      Haddock performance
      ===================
      
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
      b207b536
  7. 14 Feb, 2017 1 commit
    • rwbarton's avatar
      Check local type family instances against all imported ones · bedcb716
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      We previously checked type family instance declarations
      in a module for consistency with all instances that we happened
      to have read into the EPS or HPT. It was possible to arrange that
      an imported type family instance (used by an imported function)
      was in a module whose interface file was never read during
      compilation; then we wouldn't check consistency of local instances
      with this imported instance and as a result type safety was lost.
      
      With this patch, we still check consistency of local type family
      instances with all type family instances that we have loaded; but
      we make sure to load the interface files of all our imports that
      define family instances first. More selective consistency checking
      is left to #13102.
      
      On the other hand, we can now safely assume when we import a module
      that it has been checked for consistency with its imports. So we
      can save checking in checkFamInstConsistency, and overall we should
      have less work to do now.
      
      This patch also adds a note describing the Plan for ensuring type
      family consistency.
      
      Test Plan: Two new tests added; harbormaster
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: ggreif, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2992
      bedcb716
  8. 10 Feb, 2017 1 commit
  9. 06 Feb, 2017 2 commits
    • Matthew Pickering's avatar
      Don't return empty initial uncovered set for an unsat context · adb565aa
      Matthew Pickering authored and Ben Gamari's avatar Ben Gamari committed
      Previously when the checker encountered an unsatisfiable term of type
      context it would return an empty initial uncovered set. This caused all
      pattern matches in the context to be reported as redudant.
      
      This is arguably correct behaviour as they will never be reached but it
      is better to recover and provide accurate warnings for these cases to
      avoid error cascades. It would perhaps be better to report an error to
      the user about an inacessible branch but this is certainly better than
      many confusing redundant match warnings.
      
      Reviewers: gkaracha, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3064
      adb565aa
    • rwbarton's avatar
      Don't replace type family instances with the same LHS in GHCi (#7102) · 0abe7361
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      This fixes the easy part of #7102 by removing the logic that lets the
      user replace a type family instance with a new one with the same LHS.
      As discussed on that ticket, this is unsound in general. Better to have
      the user redefine the type family from scratch.
      
      The example from comment:7 involving loading modules into ghci is not
      fixed yet; it actually doesn't rely on the instances having the same LHS.
      This commit adds an expect_broken test for that example as well.
      
      Test Plan: T7102a for the fix; T7102 is the test not fixed yet
      
      Reviewers: dfeuer, austin, bgamari, goldfire
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2994
      0abe7361
  10. 02 Feb, 2017 2 commits
  11. 24 Jan, 2017 1 commit
  12. 23 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Don't quantify implicit type variables when quoting type signatures in TH · 729a5e45
      Ryan Scott authored
      Summary:
      A bug was introduced in GHC 8.0 in which Template Haskell-quoted type
      signatures would quantify _all_ their type variables, even the implicit ones.
      This would cause splices like this:
      
      ```
      $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a
            idProxy x = x
         |])
      ```
      
      To splice back in something that was slightly different:
      
      ```
      idProxy :: forall k proxy (a :: k). proxy a -> proxy a
      idProxy x = x
      ```
      
      Notice that the kind variable `k` is now explicitly quantified! What's worse,
      this now requires the `TypeInType` extension to be enabled.
      
      This changes the behavior of Template Haskell quoting to never explicitly
      quantify type variables which are implicitly quantified in the source.
      
      There are some other places where this behavior pops up too, including
      class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports,
      and pattern synonynms (#13018), so I fixed those too.
      
      Fixes #13018 and #13123.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj, goldfire
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2974
      
      GHC Trac Issues: #13018, #13123
      729a5e45
  13. 22 Jan, 2017 1 commit
  14. 20 Jan, 2017 2 commits
  15. 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
  16. 06 Jan, 2017 1 commit
  17. 28 Dec, 2016 1 commit
    • Tamar Christina's avatar
      Fix various issues with testsuite code on Windows · a3704409
      Tamar Christina authored
      Summary:
      Previously we would make direct calls to `diff` using `os.system`.
      On Windows `os.system` is implemented using the standard
      idiom `CreateProcess .. WaitForSingleObject ..`.
      
      This again runs afoul with the `_exec` behaviour on Windows. So we ran
      into some trouble where sometimes `diff` would return before it's done.
      
      On tests which run multiple ways, such as `8086` what happens is that
      we think the diff is done and continue. The next way tries to set things
      up again by removing any previous directory. This would then fail with
      and error saying the directory can't be removed. Which is true, because
      the previous diff code/child is still running.
      
      We shouldn't make any external calls to anything using `os.system`.
      Instead just use `runCmd` which uses `timeout`. This also ensures that if
      we hit the cygwin bug where diff or any other utility hangs, we kill it and
      continue and not hang the entire test and leave hanging processes.
      
      Further more we also:
      Ignore error lines from `removeFile` from tools in the testsuite. This is a rather large
      hammer to work around the fact that `hsc2hs` often tries to remove it's own file too early.
      When this is patched the workaround can be removed. See Trac #9775
      
      We mark `prog003` as skip. Since this test randomly fails and passes. For stability it's disabled
      but it is a genuine bug which we should find. It's something with interface files being
      overwritten. See Trac #11317
      
      when `rmtree` hits a readonly file, the `onerror` handler is raised afterwards but not
      during the tree walk. It doesn't allow you to recover and continue as we thought.
      Instead you have to explicitly start again. This is why sometimes even though we
      call `cleanup` before `os.mkdirs`, it would sometimes fail with an error that the
      folder already exists. So we now do a second walk.
      
      A new verbosity level (4) will strip the silent flags from `MAKE` invocations so you can actually
      see what's going on.
      
      Test Plan: ./validate on build bots.
      
      Reviewers: bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2894
      
      GHC Trac Issues: #12661, #11317, #9775
      a3704409
  18. 27 Dec, 2016 1 commit
    • Peter Trommler's avatar
      Testsuite: Skip failing tests on PowerPC 64-bit · 4dec7d19
      Peter Trommler authored and Ben Gamari's avatar Ben Gamari committed
      The Power ISA says the result of a division by zero is undefined.  So
      ignore stdout on PowerPC 64-bit systems.
      
      Disable ext-interp tests on 64-bit PowerPC.  We don't have support for
      PowerPC 64-bit ELF in the RTS linker, which is needed for the external
      interpreter.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, hvr, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2782
      4dec7d19
  19. 23 Dec, 2016 1 commit
    • Rufflewind's avatar
      Add caret diagnostics · 158530a5
      Rufflewind authored and Ben Gamari's avatar Ben Gamari committed
      This is controlled by -f[no-]diagnostics-show-caret.
      
      Example of what it looks like:
      ```
          |
       42 |     x = 1 + ()
          |         ^^^^^^
      ```
      This is appended to each diagnostic message.
      
      Test Plan:
      testsuite/tests/warnings/should_fail/CaretDiagnostics1
      testsuite/tests/warnings/should_fail/CaretDiagnostics2
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: joehillen, mpickering, Phyx, simonpj, alanz, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2718
      
      GHC Trac Issues: #8809
      158530a5
  20. 15 Dec, 2016 1 commit
  21. 13 Dec, 2016 1 commit
  22. 09 Dec, 2016 1 commit
  23. 08 Dec, 2016 1 commit
  24. 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
  25. 02 Dec, 2016 1 commit
  26. 29 Nov, 2016 1 commit
  27. 21 Nov, 2016 3 commits
  28. 16 Nov, 2016 1 commit
  29. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      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
  30. 12 Nov, 2016 1 commit
  31. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. A...
      3f5673f3
  32. 13 Oct, 2016 1 commit
  33. 08 Oct, 2016 1 commit