1. 21 Mar, 2020 1 commit
    • Richard Eisenberg's avatar
      Update core spec to reflect changes to Core. · 9a96ff6b
      Richard Eisenberg authored
      Key changes:
       * Adds a new rule for forall-coercions over coercion variables, which
      was implemented but conspicuously missing from the spec.
       * Adds treatment for FunCo.
       * Adds treatment for ForAllTy over coercion variables.
       * Improves commentary (including restoring a Note lost in
      03d48526) in the source.
      
      No changes to running code.
      9a96ff6b
  2. 17 Mar, 2020 2 commits
  3. 10 Mar, 2020 1 commit
  4. 24 Nov, 2019 1 commit
  5. 03 Nov, 2019 1 commit
  6. 01 Nov, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fix a bad error in tcMatchTy · 1e2e82aa
      Simon Peyton Jones authored
      This patch fixes #17395, a very subtle and hard-to-trigger
      bug in tcMatchTy.  It's all explained in
        Note [Matching in the presence of casts (2)]
      
      I have not added a regression test because it is very hard
      to trigger it, until we have the upcoming mkAppTyM patch,
      after which lacking this patch means you can't even compile
      the libraries.
      1e2e82aa
  7. 23 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Implement a coverage checker for injectivity · 1cd3fa29
      Richard Eisenberg authored
      This fixes #16512.
      
      There are lots of parts of this patch:
      
      * The main payload is in FamInst. See
      Note [Coverage condition for injective type families] there
      for the overview. But it doesn't fix the bug.
      
      * We now bump the reduction depth every time we discharge
      a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
      in TcInteract.
      
      * Exploration of this revealed a new, easy to maintain invariant
      for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
      
      * We also realized that type inference for injectivity was a
      bit incomplete. This means we exchanged lookupFlattenTyVar for
      rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
      function is monadic while the previous one was pure, necessitating
      some faff in TcInteract. Nothing too bad.
      
      * zonkCt did not maintain invariants on CTyEqCan. It's not worth
      the bother doing so, so we just transmute CTyEqCans to
      CNonCanonicals.
      
      * The pure unifier was finding the fixpoint of the returned
      substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
      Fixed now.
      
      Test cases: typecheck/should_fail/T16512{a,b}
      1cd3fa29
  8. 31 Jul, 2019 1 commit
    • Ben Gamari's avatar
      Break up TyCoRep · 371dadfb
      Ben Gamari authored
      This breaks up the monstrous TyCoReps module into several new modules by
      topic:
      
       * TyCoRep: Contains the `Coercion`, `Type`, and related type
         definitions and a few simple predicates but nothing further
      
       * TyCoPpr: Contains the the pretty-printer logic
      
       * TyCoFVs: Contains the free variable computations (and
         `tyConAppNeedsKindSig`, although I suspect this should change)
      
       * TyCoSubst: Contains the substitution logic for types and coercions
      
       * TyCoTidy: Contains the tidying logic for types
      
      While we are able to eliminate a good number of `SOURCE` imports (and
      make a few others smaller) with this change, we must introduce one new
      `hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable`
      instances for the types it defines.
      
      Metric Increase:
          haddock.Cabal
          haddock.compiler
      371dadfb
  9. 12 Jun, 2019 1 commit
  10. 15 Mar, 2019 1 commit
  11. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  12. 18 Jan, 2019 1 commit
  13. 29 Nov, 2018 1 commit
    • 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
  14. 15 Nov, 2018 1 commit
  15. 02 Nov, 2018 1 commit
  16. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  17. 15 Sep, 2018 1 commit
    • Ningning Xie's avatar
      Coercion Quantification · ea5ade34
      Ningning Xie authored
      This patch corresponds to #15497.
      
      According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2,
       we would like to have coercion quantifications back. This will
      allow us to migrate (~#) to be homogeneous, instead of its current
      heterogeneous definition. This patch is (lots of) plumbing only. There
      should be no user-visible effects.
      
      An overview of changes:
      
      - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables,
      but only in *Core*. All relevant functions are updated accordingly.
      - Small changes that should be irrelevant to the main task:
          1. removed dead code `mkTransAppCo` in Coercion
          2. removed out-dated Note Computing a coercion kind and
             roles in Coercion
          3. Added `Eq4` in Note Respecting definitional equality in
             TyCoRep, and updated `mkCastTy` accordingly.
          4. Various updates and corrections of notes and typos.
      - Haddock submodule needs to be changed too.
      
      Acknowledgments:
      This work was completed mostly during Ningning Xie's Google Summer
      of Code, sponsored by Google. It was advised by Richard Eisenberg,
      supported by NSF grant 1704041.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar
      
      Subscribers: RyanGlScott, monoidal, rwbarton, carter
      
      GHC Trac Issues: #15497
      
      Differential Revision: https://phabricator.haskell.org/D5054
      ea5ade34
  18. 21 Aug, 2018 1 commit
    • Andreas Klebinger's avatar
      Replace most occurences of foldl with foldl'. · 09c1d5af
      Andreas Klebinger authored
      This patch adds foldl' to GhcPrelude and changes must occurences
      of foldl to foldl'. This leads to better performance especially
      for quick builds where GHC does not perform strictness analysis.
      
      It does change strictness behaviour when we use foldl' to turn
      a argument list into function applications. But this is only a
      drawback if code looks ONLY at the last argument but not at the first.
      And as the benchmarks show leads to fewer allocations in practice
      at O2.
      
      Compiler performance for Nofib:
      
      O2 Allocations:
              -1 s.d.                -----            -0.0%
              +1 s.d.                -----            -0.0%
              Average                -----            -0.0%
      
      O2 Compile Time:
              -1 s.d.                -----            -2.8%
              +1 s.d.                -----            +1.3%
              Average                -----            -0.8%
      
      O0 Allocations:
              -1 s.d.                -----            -0.2%
              +1 s.d.                -----            -0.1%
              Average                -----            -0.2%
      
      Test Plan: ci
      
      Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal
      
      Reviewed By: bgamari, monoidal
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4929
      09c1d5af
  19. 25 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Treat isConstraintKind more consistently · c5d31df7
      Simon Peyton Jones authored
      It turned out that we were not being consistent
      about our use of isConstraintKind.
      
      It's delicate, because the typechecker treats Constraint and Type as
      /distinct/, whereas they are the /same/ in the rest of the compiler
      (Trac #11715).
      
      And had it wrong, which led to Trac #15412.  This patch does the
      following:
      
      * Rename isConstraintKind      to tcIsConstraintKind
               returnsConstraintKind to tcReturnsConstraintKind
        to emphasise that they use the 'tcView' view of types.
      
      * Move these functions, and some related ones (tcIsLiftedTypeKind),
        from Kind.hs, to group together in Type.hs, alongside isPredTy.
      
      It feels very unsatisfactory that these 'tcX' functions live in Type,
      but it happens because isPredTy is called later in the compiler
      too.  But it's a consequence of the 'Constraint vs Type' dilemma.
      c5d31df7
  20. 19 Jul, 2018 1 commit
  21. 10 Jul, 2018 1 commit
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      Summary:
      The patch is an attempt on #15192.
      
      It defines a new coercion rule
      
      ```
       | GRefl Role Type MCoercion
      ```
      
      which correspondes to the typing rule
      
      ```
           t1 : k1
        ------------------------------------
        GRefl r t1 MRefl: t1 ~r t1
      
           t1 : k1       co :: k1 ~ k2
        ------------------------------------
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      ```
      
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15192
      
      Differential Revision: https://phabricator.haskell.org/D4747
      55a3f855
  22. 19 Jun, 2018 1 commit
  23. 18 Jun, 2018 2 commits
    • Gabor Greif's avatar
      Typofixes in docs and comments [ci skip] · 6ac8a72f
      Gabor Greif authored
      6ac8a72f
    • Simon Peyton Jones's avatar
      Fix an infinite loop in niFixTCvSubst · d6216443
      Simon Peyton Jones authored
      Trac #14164 made GHC loop, a pretty serious error. It turned
      out that Unify.niFixTCvSubst was looping forever, because we
      had a substitution like
          a :-> ....(b :: (c :: d))....
          d :-> ...
      We correctly recognised that d was free in the range of the
      substitution, but then failed to apply it "deeeply enough"
      to the range of the substiuttion, so d was /still/ free in
      the range, and we kept on going.
      
      Trac #9106 was caused by a similar problem, but alas my
      fix to Trac #9106 was inadequate when the offending type
      variable is more deeply buried.  Urk.
      
      This time I think I've fixed it!  It's much more subtle
      than I though, and it took most of a long train journey
      to figure it out.  I wrote a long note to explain:
      Note [Finding the substitution fixpoint]
      d6216443
  24. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15195
      
      Differential Revision: https://phabricator.haskell.org/D4748
      d650729f
  25. 20 Apr, 2018 1 commit
    • Tobias Dammers's avatar
      Caching coercion roles in NthCo and coercionKindsRole refactoring · 2fbe0b51
      Tobias Dammers authored
      While addressing nonlinear behavior related to coercion roles,
      particularly `NthCo`, we noticed that coercion roles are recalculated
      often even though they should be readily at hand already in most cases.
      This patch adds a `Role` to the `NthCo` constructor so that we can cache
      them rather than having to recalculate them on the fly.
      https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
      approach.
      
      Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):
      
      GHC 8.2.1:
      ```
      ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
      ```
      
      before patch (but with other optimizations applied):
      ```
      ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
      ```
      
      after:
      ```
      ../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
      ```
      
      Introduces the following regressions:
      
      - perf/compiler/parsing001 (possibly false positive)
      - perf/compiler/T9872
      - perf/compiler/haddock.base
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11735
      
      Differential Revision: https://phabricator.haskell.org/D4394
      2fbe0b51
  26. 01 Apr, 2018 1 commit
  27. 21 Mar, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix two obscure bugs in rule matching · 3446cee0
      Simon Peyton Jones authored
      This patch fixes Trac #14777, a compiler crash.
      
      There were actually two bugs.
      
      1. In Rules.matchN, I was (consciously) not rename the template binders
         of the rule. Sadly, in rare cases an accidental coincidence of
         uniques could mean that a term variable was mapped to a type
         variable, utterly bogusly.  See "Historical note" in
         Note [Cloning the template binders] in Rules.
      
         This was hard to find, but easy to fix.
      
      2. The fix to (1) showed up a bug in Unify.hs.  The test in
         Unify.tvBindFlag was previously using the domain of the RnEnv2
         to detect locally-bound variables (e.g. when unifying under
         a forall).  That's fine when teh RnEnv2 starts empty, as it
         does in most entry points.  But the tcMatchTyKisX entry point,
         used from the rule matcher, passes in a non-empty RnEnv2 (by
         design).  Now the domain of the RnEnv doesn't idenfity those
         locally-bound variables any more :-(.
      
         Solution: extend UmEnv with a new field um_skols, to capture
         the skolems directly.  Simple, easy, works.
      3446cee0
  28. 27 Feb, 2018 2 commits
    • Simon Peyton Jones's avatar
      Comments only · 51e0a382
      Simon Peyton Jones authored
      51e0a382
    • Simon Peyton Jones's avatar
      Fix a nasty bug in the pure unifier · e99fdf77
      Simon Peyton Jones authored
      The pure unifier was building an infinite type, through a defective
      occurs check.  So GHC went into an infinite loop.
      
      Reason: we were neglecting the 'kco' part of the type, which
      'unify_ty' maintains.  Yikes.
      
      The fix is easy.  I refactored a bit to make it harder to
      go wrong in future.
      e99fdf77
  29. 22 Feb, 2018 1 commit
  30. 27 Sep, 2017 1 commit
  31. 26 Sep, 2017 1 commit
  32. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  33. 14 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Interim fix for a nasty type-matching bug · 9218ea60
      Simon Peyton Jones authored
      The type matcher in types/Unify.hs was producing a substitution
      that had variables from the template in its range.  Yikes!
      
      This patch, documented in Note [Matching in the presence of casts],
      is an interm fix.  Richard and I don't like it much, and are
      pondering a better solution (Trac #14119).
      
      All this came up in investigating Trac #13910. Alas this patch
      doesn't fix #13910, which still has ASSERT failures, so I have
      not yet added a test.  But the patch does fix a definite bug.
      9218ea60
  34. 09 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise MonoidFail instances in GHC · 346e562a
      Herbert Valerio Riedel authored
      IOW, code compiles -Wnoncanonical-monoidfail-instances clean now
      
      This is easy now since we require GHC 8.0/base-4.9 or later
      for bootstrapping.
      
      Note that we can easily enable `MonadFail` via
      
        default-extensions: MonadFailDesugaring
      
      in compiler/ghc.cabal.in
      
      which currently would point out that NatM doesn't have
      a proper `fail` method, even though failable patterns
      are made use of:
      
        compiler/nativeGen/SPARC/CodeGen.hs:425:25: error:
          * No instance for (Control.Monad.Fail.MonadFail NatM)
              arising from a do statement
              with the failable pattern ‘(dyn_c, [dyn_r])’
      346e562a
  35. 15 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14060 by more conservatively annotating TH-reified types · ad7b9452
      Ryan Scott authored
      Before, TH was quite generous in applying kind annotations to reified
      type constructors whose result kind happened to mention type variables.
      This could result in agonizingly large reified types, so this patch aims
      to quell this a bit by adopting a more nuanced algorithm for determining
      when a tycon application deserves a kind annotation.
      
      This implements the algorithm laid out in
      https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated
      `Note [Kind annotations on TyConApps]` to reflect the new wisdom.
      Essentially, instead of only checking if the result kind contains free
      variables, we also check if any of those variables do not appear free in
      injective positions in the argument kinds—only then do we put on a kind
      annotation.
      
      Bumps `haddock` submodule.
      
      Test Plan: make test TEST=T14060
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14060
      
      Differential Revision: https://phabricator.haskell.org/D3807
      ad7b9452
  36. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  37. 16 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix the pure unifier · cec7d580
      Simon Peyton Jones authored
      This patch fixes Trac #13705, by fixing a long-standing outright bug
      in the pure unifier.  I'm surprised this hasn't caused more trouble
      before now!
      cec7d580