1. 11 Jan, 2019 1 commit
  2. 08 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Be pickier about unsaturated synonyms in :kind · 6b70cf61
      Ryan Scott authored
      Summary:
      We currently permit any and all uses of unsaturated type
      synonyms and type families in GHCi's `:kind` command, which allows
      strange interactions like this one:
      
      ```
      > :set -XTypeFamilies -XPolyKinds
      > type family Id (a :: k)
      > type instance Id a = a
      > type Foo x = Maybe
      > :kind! Id Foo
      ```
      
      This is probably a stretch too far, so this patch moves to disallow
      unsaturated synonyms that aren't at the top level (we still want to
      allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt`
      with an additional `Bool` field to indicate if we are at the
      outermost level of the type being passed to `:kind` or not. See
      `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the
      full story.
      
      Test Plan: make test TEST=T16013
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: simonpj, goldfire, rwbarton, carter
      
      GHC Trac Issues: #16013
      
      Differential Revision: https://phabricator.haskell.org/D5471
      6b70cf61
  3. 21 Dec, 2018 2 commits
    • Ben Gamari's avatar
      TcRnDriver: Fix haddock-like comment · 348cb218
      Ben Gamari authored
      348cb218
    • Simon Peyton Jones's avatar
      Fix treatment of hi-boot files and dfuns · a57d5c4d
      Simon Peyton Jones authored
      Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface
      was creating a binding, in the module being compiled, for
         $fxBlah = $fBlah
      
       but $fxBlah was a /GlobalId/. But all bindings should be for
       /LocalIds/ else dependency analysis goes down the tubes.
      
      * I added a CoreLint check that an occurrence of a GlobalId
        is not bound by an binding of a LocalId.  (There is already
        a binding-site check that no binding binds a GlobalId.)
      
      * I refactored (and actually signficantly simplified) the
        tricky code for dfuns in checkHiBootIface to ensure that
        we get LocalIds for those boot-dfuns.
      
      Alas, I then got "duplicate instance" messages when compiling
      HsExpr. It turns out that this is a long-standing, but extremely
      delicate, bug: even before this patch, if you compile HsExpr
      with -ddump-tc-trace, you get "duplicate instance". Without
      -ddump-tc-trace, it's OK.  What a mess!
      
      The reason for the duplicate-instance is now explained in
      Note [Loading your own hi-boot file] in LoadIface.  I fixed
      it by a Gross Hack in LoadIface.loadInterface. This is at
      least no worse than before.
      
      But there should be a better way. I have opened #16081 for this.
      a57d5c4d
  4. 11 Dec, 2018 1 commit
    • Daniel Gröber (dxld)'s avatar
      Support registering Plugins through the GHC API · da05d79d
      Daniel Gröber (dxld) authored
      This allows tooling using the GHC API to use plugins internally.
      Hopefully this will make it possible to decouple the development of
      useful plugins from (currently) kitchen-sink type tooling projects
      such as ghc-mod or HIE -- at least to some extent.
      
      Test Plan: validate
      
      Reviewers: bgamari, mpickering
      
      Subscribers: mpickering, alanz, rwbarton, carter
      
      GHC Trac Issues: #15826
      
      Differential Revision: https://phabricator.haskell.org/D5278
      da05d79d
  5. 07 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Wibble to Taming the Kind Inference Monster · 5b7ca039
      Simon Peyton Jones authored
      I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit.
      The main payload of this patch is to fix that problem, at the cost of
      more contortions in checkConsistentFamInst.  Oh well, at least they are
      highly localised.
      
      I also update the -ddump-types code in TcRnDriver to print out some
      more expicit information about each type constructor, thus instead of
      
         DF{3} :: forall k. * -> k -> *
      
      we get
      
         data family DF{3} :: forall k. * -> k -> *
      
      Remember, this is debug-printing only.  This change is the reason
      that so many .stderr files change.
      5b7ca039
  6. 03 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      
      This patch implements the change:
      
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      
      Some miscellaneous refactoring
      
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
      03d48526
  7. 29 Nov, 2018 2 commits
    • Chaitanya Koparkar's avatar
      Fix #15953 by consistently using dumpIfSet_dyn to print debug output · dcf1f926
      Chaitanya Koparkar authored
      Summary:
      In some modules we directly dump the debugging output to STDOUT
      via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
      is enabled, that output should be written to a file. Easily fixed.
      
      Certain tests (T3017, Roles3, T12763 etc.) expect part of the
      output generated by `-ddump-types` to be in 'PprUser' style. However,
      generally we want all other debugging output to use 'PprDump'
      style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.
      
      This patch also documents some missing flags in the users guide.
      
      Reviewers: RyanGlScott, bgamari, hvr
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15953
      
      Differential Revision: https://phabricator.haskell.org/D5382
      dcf1f926
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  8. 24 Nov, 2018 1 commit
  9. 17 Nov, 2018 1 commit
  10. 11 Nov, 2018 1 commit
  11. 29 Oct, 2018 2 commits
  12. 28 Oct, 2018 2 commits
    • Ben Gamari's avatar
      Plugins: Add documentation and missing exports · 49f5c6c3
      Ben Gamari authored
      Summary:
      Previously the TcPlugin and CorePlugin type synonyms were not exporting,
      resulting in much confusion.
      
      Reviewers: mpickering
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5237
      49f5c6c3
    • Ningning Xie's avatar
      Fix `:k` command: add validity checking · c4a876d5
      Ningning Xie authored
      Summary:
      This patch fixes #15806, where we found that the `:k` command in GHCi
      misses a validity checking for the type.
      
      Missing validity checking causes `:k` to accept types that are not validated.
      For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while
      impredictivity of type instantiation shouldn't be allowed.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15806
      
      Differential Revision: https://phabricator.haskell.org/D5265
      c4a876d5
  13. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  14. 25 Oct, 2018 1 commit
  15. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Improve output from -ddump-types · 321bc1a6
      Simon Peyton Jones authored
      This patch makes a number of improvements to the output
      generated by -ddump-types
      
      * Prints data constructor separately
      * Omits empty chunks of output
      
      I was driven initially by the unhelpful existing output for
      data constructors, but ended up doing some refactoring.
      
      Lots of error message wibbles, but nothing significant.
      Certainly no change in user behaviour.
      
      (NB: It is just possible that I have failed to cleanly
           separate this patch from the next one, about
           isPredTy and friends.)
      321bc1a6
  16. 05 Oct, 2018 1 commit
  17. 04 Oct, 2018 2 commits
    • Simon Peyton Jones's avatar
      Fail fast on pattern synonyms · 9ebfa03d
      Simon Peyton Jones authored
      We were recovering too eagerly from errors in pattern-synonym
      type inference, leading to a cascade of confusing follow up errors
      (Trac #15685, #15692).
      
      The underlying issue is that a pattern synonym should have a closed,
      fixed type, with no unification variables in it.  But it wasn't!
      
      Fixing this made me change the interface to simplifyInfer slightly.
      Instead of /emitting/ a residual implication constraint, it
      now /returns/ it, so that the caller can decide what to do.
      9ebfa03d
    • Simon Peyton Jones's avatar
      Better -ddump-types · e9e66402
      Simon Peyton Jones authored
      The debug flag -ddump-types is supposed to show the type
      of Ids, and the kinds of type constructors.  It was doing
      the former but not the latter -- instead it was using
      showTyTying, which is actually less helpful when debugging.
      
      This patch changes it to print the kind and roles of the thing.
      
      I also made -ddump-types show pattern synonyms
      e9e66402
  18. 31 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Remove knot-tying bug in TcHsSyn.zonkTyVarOcc · 565ef4cc
      Simon Peyton Jones authored
      There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed
      in Trac #15552.
      
      I fixed it by
      
      * Eliminating the short-circuiting optimisation in zonkTyVarOcc,
        instead adding a finite map to get sharing of zonked unification
        variables.
      
        See Note [Sharing when zonking to Type] in TcHsSyn
      
      * On the way I /added/ the short-circuiting optimisation to
        TcMType.zonkTcTyVar, which has no such problem.  This turned
        out (based on non-systematic measurements) to be a modest win.
      
        See Note [Sharing in zonking] in TcMType
      
      On the way I renamed some of the functions in TcHsSyn:
      
      * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv
      
      * Ones that do not end in "x" (like zonkTcTypeToType), don't.
        Instead they whiz up an empty ZonkEnv.
      565ef4cc
  19. 06 Aug, 2018 1 commit
  20. 02 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove decideKindGeneralisationPlan · c955a514
      Richard Eisenberg authored
      TypeInType came with a new function: decideKindGeneralisationPlan.
      This type-level counterpart to the term-level decideGeneralisationPlan
      chose whether or not a kind should be generalized. The thinking was
      that if `let` should not be generalized, then kinds shouldn't either
      (under the same circumstances around -XMonoLocalBinds).
      
      However, this is too conservative -- the situation described in the
      motivation for "let should be be generalized" does not occur in types.
      
      This commit thus removes decideKindGeneralisationPlan, always
      generalizing.
      
      One consequence is that tc_hs_sig_type_and_gen no longer calls
      solveEqualities, which reports all unsolved constraints, instead
      relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
      of this is that reporing kind errors gets delayed more frequently.
      This seems to be a net benefit in error reporting; often, alongside
      a kind error, the type error is now reported (and users might find
      type errors easier to understand).
      
      Some of these errors ended up at the top level, where it was
      discovered that the GlobalRdrEnv containing the definitions in the
      local module was not in the TcGblEnv, and thus errors were reported
      with qualified names unnecessarily. This commit rejiggers some of
      the logic around captureTopConstraints accordingly.
      
      One error message (typecheck/should_fail/T1633)
      is a regression, mentioning the name of a default method. However,
      that problem is already reported as #10087, its solution is far from
      clear, and so I'm not addressing it here.
      
      This commit fixes #15141. As it's an internal refactor, there is
      no concrete test case for it.
      
      Along the way, we no longer need the hsib_closed field of
      HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
      and so it's been removed, simplifying the datatype structure.
      
      Along the way, I removed code in the validity checker that looks
      at coercions. This isn't related to this patch, really (though
      it was, at one point), but it's an improvement, so I kept it.
      
      This updates the haddock submodule.
      c955a514
  21. 01 Aug, 2018 1 commit
  22. 12 Jul, 2018 1 commit
    • Matthew Pickering's avatar
      Run the renamed source plugin after each HsGroup · 1a79270c
      Matthew Pickering authored
      This allows modification of each `HsGroup` after it has been renamed.
      
      The old behaviour of keeping the renamed source until later can be
      recovered if desired by using the `keepRenamedSource` plugin but it
      shouldn't really be necessary as it can be inspected in the `TcGblEnv`.
      
      Reviewers: nboldi, bgamari, alpmestan
      
      Reviewed By: nboldi, alpmestan
      
      Subscribers: alpmestan, rwbarton, thomie, carter
      
      GHC Trac Issues: #15315
      
      Differential Revision: https://phabricator.haskell.org/D4947
      1a79270c
  23. 14 Jun, 2018 1 commit
  24. 07 Jun, 2018 1 commit
  25. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  26. 30 May, 2018 1 commit
    • Tao He's avatar
      Put the `ev_binds` of main function inside `runMainIO` · 49e423e9
      Tao He authored
      This ensures that the deferred type error can be emitted correctly.
      
      For `main` function in `Main` module, we have
      
          :Main.main = GHC.TopHandler.runMainIO main
      
      When the type of `main` is not `IO t` and the
      `-fdefer-type-errors` is enabled, the `ev_binds`
      of `main` function will contain deferred type
      errors.
      
      Previously, the `ev_binds` are bound to `runMainIO main`,
      rather than `main`, the type error exception at runtime
      cannot be handled properly. See Trac #13838.
      
      This patch fix that.
      
      Test Plan: make test TEST="T13838"
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13838
      
      Differential Revision: https://phabricator.haskell.org/D4708
      49e423e9
  27. 17 May, 2018 1 commit
    • Simon Marlow's avatar
      Fix GHCi space leaks (#15111) · f27e4f62
      Simon Marlow authored
      Summary:
      There were a number of leaks causing previously loaded modules to be
      retained after a new `:load`.  This fixes enough leaks to get the
      tests to pass from D4658.
      
      Test Plan: See new tests in D4658
      
      Reviewers: niteria, bgamari, simonpj, erikd
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15111
      
      Differential Revision: https://phabricator.haskell.org/D4659
      f27e4f62
  28. 27 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG : complete for balance of hsSyn AST · c3823cba
      Alan Zimmerman authored
      Summary:
      - remove PostRn/PostTc fields
      - remove the HsVect In/Out distinction for Type, Class and Instance
      - remove PlaceHolder in favour of NoExt
      - Simplify OutputableX constraint
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4625
      c3823cba
  29. 13 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  30. 09 Apr, 2018 1 commit
  31. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  32. 02 Mar, 2018 1 commit
  33. 15 Jan, 2018 1 commit
  34. 19 Dec, 2017 1 commit
  35. 18 Dec, 2017 1 commit