1. 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
  2. 18 Jan, 2019 1 commit
  3. 21 Dec, 2018 1 commit
    • 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. 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
  5. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      
      Particular changes
      
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      
      * isCoercionType is renamed to isCoVarType
      
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
      
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
      
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
      
        Also see Note [Evidence for quantified constraints] in Type.
      
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
      0faf7fd3
  6. 19 Oct, 2018 1 commit
    • Ningning Xie's avatar
      Adding almost devoid check for covar in ForAllCo · 879db559
      Ningning Xie authored
      Summary:
      For the sake of consistency of the dependent core, there is a restriction on
      where a coercion variable can appear in ForAllCo: the coercion variable can
      appear nowhere except in coherence coercions.
      
      Currently this restriction is missing in Core. The goal of this patch is to add
      the missing restriction.
      
      After discussion, we decide: coercion variables can appear nowhere except in
      `GRefl` and `Refl`. Relaxing the restriction to include `Refl` should not break
      consistency, we premuse.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15757
      
      Differential Revision: https://phabricator.haskell.org/D5231
      879db559
  7. 04 Oct, 2018 1 commit
  8. 26 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix Lint of unsaturated type families · 4bdb10ca
      Simon Peyton Jones authored
      GHC allows types to have unsaturated type synonyms and type families,
      provided they /are/ saturated if you expand all type synonyms.
      
      TcValidity carefully checked this; see check_syn_tc_app.  But
      Lint only did half the job, adn that led to Trac #15664.
      
      This patch just teaches Core Lint to be as clever as TcValidity.
      4bdb10ca
  9. 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
  10. 13 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Allow (~) in the head of a quantified constraints · bd76875a
      Simon Peyton Jones authored
      Since the introduction of quantified constraints, GHC has rejected
      a quantified constraint with (~) in the head, thus
        f :: (forall a. blah => a ~ ty) => stuff
      
      I am frankly dubious that this is ever useful.  But /is/ necessary for
      Coercible (representation equality version of (~)) and it does no harm
      to allow it for (~) as well.  Plus, our users are asking for it
      (Trac #15359, #15625).
      
      It was really only excluded by accident, so
      this patch lifts the restriction. See TcCanonical
      Note [Equality superclasses in quantified constraints]
      
      There are a number of wrinkles:
      
      * If the context of the quantified constraint is empty, we
        can get trouble when we get down to unboxed equality (a ~# b)
        or (a ~R# b), as Trac #15625 showed. This is even more of
        a corner case, but it produced an outright crash, so I elaborated
        the superclass machinery in TcCanonical.makeStrictSuperClasses
        to add a void argument in this case.  See
        Note [Equality superclasses in quantified constraints]
      
      * The restriction on (~) was in TcValidity.checkValidInstHead.
        In lifting the restriction I discovered an old special case for
        (~), namely
            | clas_nm `elem` [ heqTyConName, eqTyConName]
            , nameModule clas_nm /= this_mod
        This was (solely) to support the strange instance
            instance a ~~ b => a ~ b
        in Data.Type.Equality. But happily that is no longer
        with us, since
           commit f265008f
           Refactor (~) to reduce the suerpclass stack
        So I removed the special case.
      
      * I found that the Core invariants on when we could have
             co = <expr>
        were entirely not written down. (Getting this wrong ws
        the proximate source of the crash in Trac #15625.  So
      
        - Documented them better in CoreSyn
            Note [CoreSyn type and coercion invariant],
        - Modified CoreOpt and CoreLint to match
        - Modified CoreUtils.bindNonRec to match
        - Made MkCore.mkCoreLet use bindNonRec, rather
          than duplicate its logic
        - Made Simplify.rebuildCase case-to-let respect
            Note [CoreSyn type and coercion invariant],
      bd76875a
  11. 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
  12. 06 Jul, 2018 2 commits
    • Matthew Pickering's avatar
      Simplify lintIdUnfolding · 379bb201
      Matthew Pickering authored
      The logic for `DFunUnfolding` seemed quite confusing and unecessary. A
      simpler strategy uses `maybeUnfoldingTemplate`, as that is what is
      actually used when doing inlining and checking that has the right type.
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4919
      379bb201
    • Ryan Scott's avatar
      Make a variant of mkCastErr for kind coercions · 18cedbb5
      Ryan Scott authored
      Summary:
      I discovered when debugging #15346 that the Core Lint error
      message for ill typed casts always mentions types of enclosed
      //expressions//, even if the thing being casted is actually a type.
      This generalizes `mkCastErr` a bit to allow it to give the proper
      labelling for kind coercions.
      
      Test Plan: Run on failing program in #15346, read the Core Lint error
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4940
      18cedbb5
  13. 18 Jun, 2018 1 commit
  14. 15 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix corner case in typeKind, plus refactoring · f903e551
      Simon Peyton Jones authored
      This is a continuation of
      
          commit 9d600ea6
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Fri Jun 1 16:36:57 2018 +0100
      
              Expand type synonyms when Linting a forall
      
      That patch pointed out that there was a lurking hole in
      typeKind, where it could return an ill-scoped kind, because
      of not expanding type synonyms enough.
      
      This patch fixes it, quite nicely
      
      * Use occCheckExpand to expand those synonyms (it was always
        designed for that exact purpose), and call it from
               Type.typeKind
               CoreUtils.coreAltType
               CoreLint.lintTYpe
      
      * Consequently, move occCheckExpand from TcUnify.hs to
        Type.hs, and generalise it to take a list of type variables.
      
      I also tidied up lintType a bit.
      f903e551
  15. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Expand type synonyms when Linting a forall · 9d600ea6
      Simon Peyton Jones authored
      Trac #14939 showed a type like
         type Alg cls ob = ob
         f :: forall (cls :: * -> Constraint) (b :: Alg cls *). b
      
      where the kind of the forall looks like (Alg cls *), with a
      free cls. This tripped up Core Lint.
      
      I fixed this by making Core Lint a bit more forgiving, expanding
      type synonyms if necessary.
      
      I'm worried that this might not be the whole story; notably
      typeKind looks suspect.  But it certainly fixes this problem.
      9d600ea6
  16. 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
  17. 27 Apr, 2018 1 commit
    • Simon Peyton Jones's avatar
      Better linting for types · 6da5b877
      Simon Peyton Jones authored
      Trac #15057 described deficiencies in the linting for types
      involving type synonyms.  This patch fixes an earlier attempt.
      
      The moving parts are desrcribed in
        Note [Linting type synonym applications]
      
      Not a big deal.
      6da5b877
  18. 20 Apr, 2018 2 commits
    • 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
    • Ryan Scott's avatar
      Lint types in newFamInst · 257c13d8
      Ryan Scott authored
      We weren't linting the types used in `newFamInst`, which
      might have been why #15012 went undiscovered for so long. Let's fix
      that.
      
      One has to be surprisingly careful with expanding type synonyms in
      `lintType`, since in the offending program (simplified):
      
      ```lang=haskell
      type FakeOut a = Int
      
      type family TF a
      type instance TF Int = FakeOut a
      ```
      
      If one expands type synonyms, then `FakeOut a` will expand to
      `Int`, which masks the issue (that `a` is unbound). I added an
      extra Lint flag to configure whether type synonyms should be
      expanded or not in Lint, and disabled this when calling `lintTypes`
      from `newFamInst`.
      
      As evidence that this works, I ran it on the offending program
      from #15012, and voilà:
      
      ```
      $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint
      [1 of 1] Compiling Foo              ( Bug.hs, Bug.o )
      ghc-stage2: panic! (the 'impossible' happened)
        (GHC version 8.5.20180417 for x86_64-unknown-linux):
              Core Lint error
        <no location info>: warning:
            In the type ‘... (Rec0 (FakeOut b_a1Qt))))’
            @ b_a1Qt is out of scope
      ```
      
      Test Plan: make test TEST=T15057
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15057
      
      Differential Revision: https://phabricator.haskell.org/D4611
      257c13d8
  19. 06 Mar, 2018 1 commit
    • niteria's avatar
      Allow top level ticked string literals · 5bc195a2
      niteria authored
      This reverts f5b275a2
      and changes the places that looked for `Lit (MachStr _))`
      to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
      necessary.
      Also updated relevant comments.
      
      Test Plan:
      I added 3 new tests that previously reproduced.
      GHC HEAD now builds with -g
      
      Reviewers: simonpj, simonmar, bgamari, hvr, goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14779
      
      Differential Revision: https://phabricator.haskell.org/D4470
      5bc195a2
  20. 27 Feb, 2018 1 commit
  21. 07 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix utterly bogus TagToEnum rule in caseRules · 4aa98f4a
      Simon Peyton Jones authored
      In prelRules we had:
      
        tx_con_tte :: DynFlags -> AltCon -> AltCon
        tx_con_tte _      DEFAULT      = DEFAULT
        tx_con_tte dflags (DataAlt dc)
          | tag == 0  = DEFAULT   -- See Note [caseRules for tagToEnum]
          | otherwise = LitAlt (mkMachInt dflags (toInteger tag))
      
      The tag==0 case is totally wrong, and led directly to Trac #14768.
      
      See "Beware" in Note [caseRules for tagToEnum] (in the patch).
      
      Easily fixed, though!
      4aa98f4a
  22. 01 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Add -ddump-ds-preopt · efce943c
      Simon Peyton Jones authored
      This allows you to see the output immediately after desugaring
      but before any optimisation.
      
      I've wanted this for some time, but I was triggered into action
      by Trac #13032 comment:9.
      
      Interestingly, the change means that with -dcore-lint we will
      now Lint the output before the very simple optimiser;
      and this showed up Trac #14749.  But that's not the fault
      of -ddump-ds-preopt!
      efce943c
  23. 15 Jan, 2018 1 commit
  24. 21 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
  25. 09 Nov, 2017 2 commits
  26. 30 Oct, 2017 1 commit
    • Michal Terepeta's avatar
      Allow packing constructor fields · cca2d6b7
      Michal Terepeta authored
      This is another step for fixing #13825 and is based on D38 by Simon
      Marlow.
      
      The change allows storing multiple constructor fields within the same
      word. This currently applies only to `Float`s, e.g.,
      ```
      data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float
      ```
      on 64-bit arch, will now store both fields within the same constructor
      word. For `WordX/IntX` we'll need to introduce new primop types.
      
      Main changes:
      
      - We now use sizes in bytes when we compute the offsets for
        constructor fields in `StgCmmLayout` and introduce padding if
        necessary (word-sized fields are still word-aligned)
      
      - `ByteCodeGen` had to be updated to correctly construct the data
        types. This required some new bytecode instructions to allow pushing
        things that are not full words onto the stack (and updating
        `Interpreter.c`). Note that we only use the packed stuff when
        constructing data types (i.e., for `PACK`), in all other cases the
        behavior should not change.
      
      - `RtClosureInspect` was changed to handle the new layout when
        extracting subterms. This seems to be used by things like `:print`.
        I've also added a test for this.
      
      - I deviated slightly from Simon's approach and use `PrimRep` instead
        of `ArgRep` for computing the size of fields.  This seemed more
        natural and in the future we'll probably want to introduce new
        primitive types (e.g., `Int8#`) and `PrimRep` seems like a better
        place to do that (where we already have `Int64Rep` for example).
        `ArgRep` on the other hand seems to be more focused on calling
        functions.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd
      
      Reviewed By: bgamari
      
      Subscribers: maoe, rwbarton, thomie
      
      GHC Trac Issues: #13825
      
      Differential Revision: https://phabricator.haskell.org/D3809
      cca2d6b7
  27. 29 Oct, 2017 1 commit
    • Joachim Breitner's avatar
      Implement a dedicated exitfication pass #14152 · 0e953da1
      Joachim Breitner authored
      The idea is described in #14152, and can be summarized: Float the exit
      path out of a joinrec, so that the simplifier can do more with it.
      See the test case for a nice example.
      
      The floating goes against what the simplifier usually does, hence we
      need to be careful not inline them back.
      
      The position of exitification in the pipeline was chosen after a small
      amount of experimentation, but may need to be improved. For example,
      exitification can allow rewrite rules to fire, but for that it would
      have to happen before the `simpl_phases`.
      
      Perf.haskell.org reports these nice performance wins:
      
          Nofib allocations
          fannkuch-redux    78446640  - 99.92%      64560
          k-nucleotide     109466384  - 91.32%    9502040
          simple            72424696  -  5.96%   68109560
      
          Nofib instruction counts
          fannkuch-redux  1744331636  -  3.86% 1676999519
          k-nucleotide    2318221965  -  6.30% 2172067260
          scs             1978470869  -  3.35% 1912263779
          simple           669858104  -  3.38%  647206739
          spectral-norm    186423292  -  5.37%  176411536
      
      Differential Revision: https://phabricator.haskell.org/D3903
      0e953da1
  28. 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
  29. 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
  30. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add debugPprType · 805b29bb
      Simon Peyton Jones authored
      We pretty-print a type by converting it to an IfaceType and
      pretty-printing that.  But
       (a) that's a bit indirect, and
       (b) delibrately loses information about (e.g.) the kind
            on the /occurrences/ of a type variable
      
      So this patch implements debugPprType, which pretty prints
      the type directly, with no fancy formatting.  It's just used
      for debugging.
      
      I took the opportunity to refactor the debug-pretty-printing
      machinery a little.  In particular, define these functions
      and use them:
      
        ifPprDeubug :: SDoc -> SDOc -> SDoc
          -- Says what to do with and without -dppr-debug
        whenPprDebug :: SDoc -> SDoc
          -- Says what to do with  -dppr-debug; without is empty
        getPprDebug :: (Bool -> SDoc) -> SDoc
      
      getPprDebug used to be called sdocPprDebugWith
      whenPprDebug used to be called ifPprDebug
      
      So a lot of files get touched in a very mechanical way
      805b29bb
  31. 29 Aug, 2017 1 commit
  32. 18 Aug, 2017 1 commit
  33. 12 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Use NonEmpty lists to represent lists of duplicate elements · 7d699782
      Ryan Scott authored
      Summary:
      Three functions in `ListSetOps` which compute duplicate elements
      represent lists of duplicates of `[a]`. This is a really bad way to go about
      things, because these lists are guaranteed to always have at least one element
      (the "representative" of the duplicates), and several places in the GHC API
      call `head` (a partial function) on these lists of duplicates to retrieve the
      representative.
      
      This changes the representation of duplicates to `NonEmpty` lists instead,
      which allow for many partial uses of `head` to be made total.
      
      Fixes #13823.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13823
      
      Differential Revision: https://phabricator.haskell.org/D3823
      7d699782
  34. 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
  35. 02 Jun, 2017 1 commit
    • Ryan Scott's avatar
      Use lengthIs and friends in more places · a786b136
      Ryan Scott authored
      While investigating #12545, I discovered several places in the code
      that performed length-checks like so:
      
      ```
      length ts == 4
      ```
      
      This is not ideal, since the length of `ts` could be much longer than 4,
      and we'd be doing way more work than necessary! There are already a slew
      of helper functions in `Util` such as `lengthIs` that are designed to do
      this efficiently, so I found every place where they ought to be used and
      did just that. I also defined a couple more utility functions for list
      length that were common patterns (e.g., `ltLength`).
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, goldfire, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: goldfire, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3622
      a786b136
  36. 03 May, 2017 1 commit
  37. 06 Apr, 2017 1 commit