1. 19 Apr, 2019 1 commit
    • Alec Theriault's avatar
      TH: make `Lift` and `TExp` levity-polymorphic · 57cf1133
      Alec Theriault authored
      Besides the obvious benefits of being able to manipulate `TExp`'s of
      unboxed types, this also simplified `-XDeriveLift` all while making
      it more capable.
        * `ghc-prim` is explicitly depended upon by `template-haskell`
        * The following TH things are parametrized over `RuntimeRep`:
            - `TExp(..)`
            - `unTypeQ`
            - `unsafeTExpCoerce`
            - `Lift(..)`
        * The following instances have been added to `Lift`:
            - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#`
            - unboxed tuples of lifted types up to arity 7
            - unboxed sums of lifted types up to arity 7
          Ideally we would have levity-polymorphic _instances_ of unboxed
          tuples and sums.
        * The code generated by `-XDeriveLift` uses expression quotes
          instead of generating large amounts of TH code and having
          special hard-coded cases for some unboxed types.
  2. 15 Mar, 2019 1 commit
  3. 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
      * 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
  4. 14 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Make a smart mkAppTyM · 68278382
      Simon Peyton Jones authored
      This patch finally delivers on Trac #15952.  Specifically
      * Completely remove Note [The tcType invariant], along with
        its complicated consequences (IT1-IT6).
      * Replace Note [The well-kinded type invariant] with:
            Note [The Purely Kinded Type Invariant (PKTI)]
      * Instead, establish the (PKTI) in TcHsType.tcInferApps,
        by using a new function mkAppTyM when building a type
        application.  See Note [mkAppTyM].
      * As a result we can remove the delicate mkNakedXX functions
        entirely.  Specifically, mkNakedCastTy retained lots of
        extremly delicate Refl coercions which just cluttered
        everything up, and(worse) were very vulnerable to being
        silently eliminated by (say) substTy. This led to a
        succession of bug reports.
      The result is noticeably simpler to explain, simpler
      to code, and Richard and I are much more confident that
      it is correct.
      It does not actually fix any bugs, but it brings us closer.
      E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
      do so.  However, it makes it much easier to fix.
      I also did a raft of other minor refactorings:
      * Use tcTypeKind consistently in the type checker
      * Rename tcInstTyBinders to tcInvisibleTyBinders,
        and refactor it a bit
      * Refactor tcEqType, pickyEqType, tcEqTypeVis
        Simpler, probably more efficient.
      * Make zonkTcType zonk TcTyCons, at least if they have
        any free unification variables -- see zonk_tc_tycon
        in TcMType.zonkTcTypeMapper.
        Not zonking these TcTyCons was actually a bug before.
      * Simplify try_to_reduce_no_cache in TcFlatten (a lot)
      * Combine checkExpectedKind and checkExpectedKindX.
        And then combine the invisible-binder instantation code
        Much simpler now.
      * Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
        I'm not sure how I came across this originally.
      * Fix a little bug in TyCoRep.isUnliftedRuntimeRep
        (the ASSERT was over-zealous).  Again I'm not certain
        how I encountered this.
      * Add a missing solveLocalEqualities in
        I came across this when trying to get level numbers
  5. 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).
  6. 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
      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.
      * 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
      * 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
  7. 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.
      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
  8. 27 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor (~) to reduce the suerpclass stack · f265008f
      Simon Peyton Jones authored
      The constraint (~) used to be (effectively):
        class a ~~ b => (a :: k) ~ (b :: k)
      but, with this patch, it is now defined uniformly with
      (~~) and Coercible like this:
        class a ~# b => (a :: k) ~ (b :: k)
        * One less superclass selection when goinng from (~) to (~#)
          Better for compile time and better for debugging with -ddump-simpl
        * The code for (~), (~~), and Coercible looks uniform, and appears
          together, e.g. in TysWiredIn and ClsInst.matchGlobalInst.
          Previously the code for (~) was different, and unique.
      Not only is this simpler, but it also makes the compiler a bit faster;
        T12227: 9% less allocation
        T12545: 7% less allocation
      This patch fixes Trac #15421
  9. 19 Jun, 2018 1 commit
  10. 17 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Provide a better error message for unpromotable data constructor contexts · c6375411
      Ryan Scott authored
      Trac #14845 brought to light a corner case where a data
      constructor could not be promoted (even with `-XTypeInType`) due to
      an unpromotable constraint in its context. However, the error message
      was less than helpful, so this patch adds an additional check to
      `tcTyVar` catch unpromotable data constructors like these //before//
      they're promoted, and to give a sensible error message in such cases.
      Test Plan: make test TEST="T13895 T14845"
      Reviewers: simonpj, goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #13895, #14845
      Differential Revision: https://phabricator.haskell.org/D4728
  11. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      The main ticket is Trac #2893, but also relevant are
        #9123 (especially!  higher kinded roles)
      The wiki page is
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      Here is the relevant Note:
      Note [Quantified constraints]
      The -XQuantifiedConstraints extension allows type-class contexts like
        data Rose f x = Rose x (f (Rose f x))
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      Some other related refactoring
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
  12. 09 Apr, 2018 1 commit
  13. 07 Apr, 2018 1 commit
  14. 26 Jan, 2018 1 commit
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      Ideally, I'd like to do
          type EvTerm = CoreExpr
      and the type checker builds the evidence terms as it goes. This failed,
      becuase the evidence for `Typeable` refers to local identifiers that are
      added *after* the typechecker solves constraints. Therefore, `EvTerm`
      stays a data type with two constructors: `EvExpr` for `CoreExpr`
      evidence, and `EvTypeable` for the others.
      Delted `Note [Memoising typeOf]`, its reference (and presumably
      relevance) was removed in 8fa4bf9a.
      Differential Revision: https://phabricator.haskell.org/D4341
  15. 26 Dec, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #14618 by applying a subst in deeplyInstantiate · 722a6584
      Richard Eisenberg authored
      Previously, we were inexplicably not applying an instantiating
      substitution to arguments in non-prenex types. It's amazing this
      has been around for so long! I guess there aren't a lot of non-prenex
      types around.
      test case: typecheck/should_fail/T14618
  16. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      Reverts haddock submodule.
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
  17. 11 Nov, 2017 1 commit
  18. 08 Nov, 2017 1 commit
  19. 07 Nov, 2017 2 commits
  20. 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
      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
  21. 31 Aug, 2017 1 commit
  22. 29 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Use a well-kinded substitution to instantiate · 4455c86d
      Simon Peyton Jones authored
      In tcDataConPat we were creating an ill-kinded substitution
      -- or at least one that is well kinded only after you have solved
      other equalities.  THat led to a crash, because the instantiated
      data con type was ill-kinded.
      This patch guarantees that the instantiating substitution is
      Fixed Trac #14154
  23. 27 Jul, 2017 2 commits
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      Test case: typecheck/should_fail/T13819
  24. 11 Jul, 2017 1 commit
    • Ömer Sinan Ağacan's avatar
      Mention which -Werror promoted a warning to an error · 4befb415
      Ömer Sinan Ağacan authored
      Previously -Werror or -Werror=flag printed warnings as usual and then
      these two lines:
          <no location info>: error:
          Failing due to -Werror.
      This is not ideal: first, it's not clear which flag made one of the
      warnings an
      error. Second, warning messages are not modified in any way, so there's
      no way
      to know which warnings caused this error.
      With this patch we (1) promote warning messages to error messages if a
      -Werror is enabled (2) mention which -Werror is used during this
          [1 of 1] Compiling Main             ( test.hs, test.o )
          test.hs:9:10: warning: [-Wincomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
          9 | sInt s = case s of
            |          ^^^^^^^^^...
          test.hs:12:14: warning: [-Wmissing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
          <no location info>: error:
          Failing due to -Werror.
          [1 of 1] Compiling Main             ( test.hs, test.o )
          test.hs:9:10: error: [-Wincomplete-patterns,
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
          9 | sInt s = case s of
            |          ^^^^^^^^^...
          test.hs:12:14: error: [-Wmissing-fields, -Werror=missing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      Test Plan: - Update old tests, add new tests if there aren't any
      relevant tests
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3709
  25. 03 Jul, 2017 1 commit
  26. 29 Jun, 2017 1 commit
  27. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      Updating Haddock submodule to match.
      Test Plan: ./validate
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      Subscribers: rwbarton, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D3609
  28. 08 May, 2017 1 commit
  29. 10 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      The main changes are
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      * The type in SigSkol is now the /un/-skolemised version
      * pprSkolemInfo uses the info to make the tidy type line up
      Lots of error message wibbles!
  30. 30 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Check that a default type signature aligns with the non-default signature · 7363d538
      Ryan Scott authored
      Before, GHC was extremely permissive about the form a default type
      signature could take on in a class declaration. Notably, it would accept
      garbage like this:
        class Monad m => MonadSupply m where
          fresh :: m Integer
          default fresh :: MonadTrans t => t m Integer
          fresh = lift fresh
      And then give an extremely confusing error message when you actually
      tried to declare an empty instance of MonadSupply. We now do extra
      validity checking of default type signatures to ensure that they align
      with their non-default type signature counterparts. That is, a default
      type signature is allowed to differ from the non-default one only in its
      context - they must otherwise be alpha-equivalent.
      Fixes #12918.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, austin, bgamari
      Reviewed By: bgamari
      Subscribers: mpickering, dfeuer, thomie
      Differential Revision: https://phabricator.haskell.org/D2983
      GHC Trac Issues: #12918
  31. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      Updates haddock submodule to match the AST changes.
      There are three issues outstanding
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
         This needs to be fixed by keeping the parens, but I do not know where ...
  32. 02 Dec, 2016 1 commit
  33. 02 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Get rid of TcTyVars more assiduously · 99689492
      Simon Peyton Jones authored
      * I found a bug in 'generalize' in TcTyClsDecls.kcTyClGroup, where
        the kind variables weren't being turned into proper TyVars, so
        we got (skolem) TcTyVars in TyCons, which shouldn't happen.  Fix
        was easy.
      * Similarly TcHsType.kindGeneralizeType wasn't turning the forall'd
        TcTyVars into TyVars.  To achieve this I defined TcHsTyn.zonkSigType.
      * All this allowed me to remove awkward and ill-explained bit of
        footwork on DFunIds in Inst.newClsInst
      This is just refactoring, but it does make the printout from
      -ddump-deriv make a bit more sense by not grautuitiously cloning
      type variables.  In the display I was seeing
         instance C [a_df4] where
            f x = ...a_dx5...
      where actually the d_df4 and a_dx5 were the same.
  34. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      4. Add a TcLevel to SkolemTvs. This will be useful generally
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
         This turned out to be much simpler.  Less code, more
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
      All these changes led to quite bit of error message wibbling
  35. 08 Oct, 2016 1 commit
  36. 25 Jun, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Refactor tcInferArgs and add comments. · 4cc5a39e
      eir@cis.upenn.edu authored
      This removes an unnecessary loop looking for invisible binders
      and tries to clarify what the very closely-related functions
      tcInferArgs, tc_infer_args, tcInferApps all do.
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      > data VisibilityFlag = Visible | Specified | Invisible
      > data ArgFlag = Required | Specified | Inferred
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
  37. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
        - tyConBinders :: [TyConBinder]
      The new data types look like this:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      Some smaller points
      * Nice new functions
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.