1. 22 Nov, 2013 6 commits
    • Joachim Breitner's avatar
      Add ctLoc = ctev_loc . cc_ev · 310e7e7f
      Joachim Breitner authored
    • Joachim Breitner's avatar
    • Joachim Breitner's avatar
    • Joachim Breitner's avatar
    • Joachim Breitner's avatar
      Make SubGoalDepth a type of its own · e42ddfe1
      Joachim Breitner authored
      In preparation of counting type function applications and constraint
      resolving separately.
    • Simon Peyton Jones's avatar
      A raft of changes driven by Trac #8540 · 78814882
      Simon Peyton Jones authored
      The root cause of #8450 is that the new Template Haskell story, with
      the renamer doing more of the work of Template Haskell, wasn't dealing
      correctly with the keepAlive problem.  Consider
          g = ..blah...
          f = [| g |]
      Then f's RHS refers to g's name but not to g, so g was being discarded
      as dead code.
      Fixing this sucked me into a deep swamp of understanding how all the moving
      parts of hte new Template Haskell fit together, leading to a large collection
      of related changes and better documentation.  Specifically:
      * Instead of putting the TH level of a binder in the LocalRdrEnv, there
        is now a separate field
            tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel)
        in the TcLclEnv, which records for each binder
           a) whether it is syntactically a top-level binder or not
           b) its TH level
        This deals uniformly with top-level and non-top-level binders, which was
        previously dealt with via greviously-delicate meddling with Internal and
        External Names.  Much better.
      * As a result I could remove the tct_level field of ATcId.
      * There are consequential changes in TcEnv too, which must also extend the
        level bindings.  Again, more clarity.
        I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used
        during kind inference, for (AThing kind) and APromotionErr; and that is
        relevant to whether we want to extend the tcl_th_bndrs field (no).
      * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the
        qual_gre code which said "Seems like 5 times as much work as it deserves!".
        Instead, RdrName.pickGREs makes the Internal names shadow External ones.
      * I moved the checkThLocalName cross-stage test to finishHsVar; previously
        we weren't doing the test at all in the OpApp case!
      * Quite a few changes (shortening the code) in the cross-stage checking code
        in TcExpr and RnSplice, notably to move the keepAlive call to the renamer
      One leftover piece:
      * In TcEnv I removed tcExtendGhciEnv and refactored
        tcExtendGlobalTyVars; this is really related to the next commit, but
        it was too hard to disentangle.
  2. 06 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      Refactor the constraint solver (again!) · 06aac68d
      Simon Peyton Jones authored
      There are three core changes here:
      a) In the constraint-solver pipeline.
         Given a work-item 'wi', the old scheme was:
            let relevant = getRelevantInerts wi
            interact 'wi' with each constraint in 'relevant'
         Bu now we have a single step
            interact 'wi' with the inert-set
         This turns out to avoid duplication, between getRelevantInerts
         (which needs to know which are relevant) and the interact step.
         Simpler, cleaner.
         This in turn made it sensible to combine the 'spontaneous solve'
         stage into the 'interact with inerts' stage.
      b) Wanteds are no longer used to rewrite wanteds.  See Trac #8450.
         This in turn means that the inert set may have
           - many CFunEqCans with the same LHS
           - many CTyEqCans  with the same LHS
         Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs
      c) Some refactoring of the representation of the inert set,
         Notably inert_dicts and inert_funeqs are indexed by Class and TyCon
         respectively, so we can easily get all the constraints relevant to
         that class or tycon
      There are many knock on effects!  This started as a small job but I
      ended up doing qite a lot.  Some error messages in the test suite
      really did improve as a result of (b)
  3. 25 Oct, 2013 2 commits
  4. 12 Oct, 2013 1 commit
  5. 08 Oct, 2013 1 commit
  6. 04 Oct, 2013 4 commits
  7. 18 Sep, 2013 1 commit
  8. 10 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for "relevant bindings" again (Trac #8233) · 9039108b
      Simon Peyton Jones authored
      This patch makes a number of related improvements:
      * Displays relevant bindings in innermost-first order.
        The inner ones are closer to the error.
      * Does not display syntactically top-level bindings,
        unless you say -fno-max-relevant-bindings.
        This is what Trac #8233 was mainly about
      * Makes the TopLevelFlag in a TcIdBinder really mean
        "syntactically top level".  It was a bit vague before.
      There was some associated simplification, because we no longer
      need to pas a TopLevelFlag to tcMonoBinds and friends.
  9. 29 Aug, 2013 1 commit
  10. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
  11. 12 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Fix the constraint simplifier (Trac #7967) · 262cab0f
      Simon Peyton Jones authored
      Richard's bug report showed up a couple of subtleties in the constraint solver
      * We can strengthen the kind invariants on CTyEqCan and CFunEqCan
          See Note [Kind orientation for CTyEqCan]
          and Note [Kind orientation for CFunEqCan] in TcRnTypes
        There are some changes to reOrient and checkKind in TcCanonical
        to support these stronger invarants.
      * In TcSimplify we must make sure that we re-simplify if defaultTyVar
        does anything.  See Note [Must simplify after defaulting] in TcSimplify.
      The usual round of refactoring follows!
  12. 23 Apr, 2013 1 commit
  13. 22 Apr, 2013 1 commit
    • Simon Peyton Jones's avatar
      Further wibbbling to type error message reporting · 2a7f4de3
      Simon Peyton Jones authored
      * We now never report derived-constraint type errors, even
        in the "insolubles".  See Note [Insoluble derived constraints]
        in TcRnTypes.
      * The cec_suppress mechanism in TcErrors is refactored a bit so that:
         - We suppress *all* errors in unreachable code (they can be jolly
         - We no longer suppress *all* non-insoluble errors if there are *any
           insolubles anywhere.  Instead we are a bit more refined.
        See Note [Suppressing error messages] in TcErrors
  14. 21 Apr, 2013 1 commit
  15. 03 Mar, 2013 1 commit
    • Simon Peyton Jones's avatar
      Treat equalities with incompatible kinds as "irreducible" constraints · c969cc3d
      Simon Peyton Jones authored
      Originally we had the invariant that CTyEqCan and CFunEqCan have LHS
      and RHS with compatible kinds.  This is important because if they have
      different kinds, then a substitution using the CTyEqCan can give rise
      to an ill-kinded type, which in turn makes typeKind crash, and this
      led to Trac #7696.  (The possibility of this happening really only
      occurred when we introduced kind polymorphism.)
      I thought at first this was going to be really awkward to solve, but
      happily it turned out to be easy.  We already have CIrredEvCan
      constraints, which are "stuck"; we can't use them and we can't solve
      them.  Yet. After some substitution from solving other constraints we
      may be able to make progress.
      So for equality constraints where the LHS and RHS don't have compatible kinds
      (although perhaps not YET compatible, eg k and *, just needing to
      unify k := *), we now generate a CIrredEvCan, plus the necessary kind
      equality constraint.
      This entailed some refactoring of course, but only in TcCanonical.  In
      particular, the emitKindConstraint code has gone, in favour of a kind
      check in canEqLeaf.  See Note [Equalities with incompatible kinds] in
      TcCanonical, and Note [CIrredEvCan constraints] in TcRnTypes
  16. 14 Feb, 2013 1 commit
    • Simon Peyton Jones's avatar
      Add OverloadedLists, allowing list syntax to be overloaded · 3234a4ad
      Simon Peyton Jones authored
      This work was all done by
         Achim Krause <achim.t.krause@gmail.com>
         George Giorgidze <giorgidze@gmail.com>
         Weijers Jeroen <jeroen.weijers@uni-tuebingen.de>
      It allows list syntax, such as [a,b], [a..b] and so on, to be
      overloaded so that it works for a variety of types.
      The design is described here:
      Eg. you can use it for maps, so that
              [(1,"foo"), (4,"bar")] :: Map Int String
      The main changes
       * The ExplicitList constructor of HsExpr gets witness field
       * Ditto ArithSeq constructor
       * Ditto the ListPat constructor of HsPat
      Everything else flows from this.
  17. 30 Jan, 2013 2 commits
  18. 08 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer the ambiguity test for user type signatures · 97db0edc
      Simon Peyton Jones authored
      Two main changes. First, re-engineer the ambiguity test.  Previously
      TcMType.checkAmbiguity used a rather syntactic test to detect some
      types that are certainly ambiguous.  But a much easier test is available,
      and it is used for inferred types in TcBinds. Namely
          <type> is ambiguous
         <type> `TcUnify.isSubType` <type>
      fails to hold, where "isSubType" means "is provably more polymorphic than".
            C a => Int
      is ambiguous, because isSubType instantiates the (C a => Int)
      to (C alpha => Int) and then tries to deduce (C alpha) from (C a). This is
      Martin Sulzmann's definition of ambiguity.  (Defn 10 of "Understanding
      functional dependencies via constraint handling rules", JFP.)
      This change is neat, reduces code, and correctly rejects more programs.
      However is *is* just possible to have a useful program that would be
      rejected. For example
                class C a b
                f :: C Int b => Int -> Int
      Here 'f' would be rejected as having an ambiguous type. But it is
      just possible that, at a *call* site there might be an instance
      declaration  instance C Int b, which does not constrain 'b' at all.
      This is pretty strange -- why is 'b' overloaded at all? -- but it's
      possible, so I also added a flag -XAllowAmbiguousTypes that simply
      removes the ambiguity check.  Let's see if anyone cares.  Meanwhile
      the earlier error report will be useful for everyone else.
      A handful of regression tests had to be adjusted as a result, because
      they used ambiguous types, somewhat accidentally.
      Second, split TcMType (already too large) into two
        * TcMType: a low-level module dealing with monadic operations like
          zonking, creating new evidence variables, etc
        * TcValidity: a brand-new higher-level module dealing with
          validity checking for types: checkValidType, checkValidInstance,
          checkFamInstPats etc
      Apart from the fact that TcMType was too big, this allows TcValidity
      to import TcUnify(tcSubType) without causing a loop.
  19. 22 Dec, 2012 1 commit
    • eir@cis.upenn.edu's avatar
      Implement overlapping type family instances. · 8366792e
      eir@cis.upenn.edu authored
      An ordered, overlapping type family instance is introduced by 'type
      where', followed by equations. See the new section in the user manual
      ( for details. The canonical example is Boolean equality at the
      type family Equals (a :: k) (b :: k) :: Bool
      type instance where
        Equals a a = True
        Equals a b = False
      A branched family instance, such as this one, checks its equations in
      and applies only the first the matches. As explained in the note
      checking within groups] in FamInstEnv.lhs, we must be careful not to
      say, (Equals Int b) to False, because b might later unify with Int.
      This commit includes all of the commits on the overlapping-tyfams
      branch. SPJ
      requested that I combine all my commits over the past several months
      into one
      monolithic commit. The following GHC repos are affected: ghc, testsuite,
      utils/haddock, libraries/template-haskell, and libraries/dph.
      Here are some details for the interested:
      - The definition of CoAxiom has been moved from TyCon.lhs to a
        new file CoAxiom.lhs. I made this decision because of the
        number of definitions necessary to support BranchList.
      - BranchList is a GADT whose type tracks whether it is a
        singleton list or not-necessarily-a-singleton-list. The reason
        I introduced this type is to increase static checking of places
        where GHC code assumes that a FamInst or CoAxiom is indeed a
        singleton. This assumption takes place roughly 10 times
        throughout the code. I was worried that a future change to GHC
        would invalidate the assumption, and GHC might subtly fail to
        do the right thing. By explicitly labeling CoAxioms and
        FamInsts as being Unbranched (singleton) or
        Branched (not-necessarily-singleton), we make this assumption
        explicit and checkable. Furthermore, to enforce the accuracy of
        this label, the list of branches of a CoAxiom or FamInst is
        stored using a BranchList, whose constructors constrain its
        type index appropriately.
      I think that the decision to use BranchList is probably the most
      controversial decision I made from a code design point of view.
      Although I provide conversions to/from ordinary lists, it is more
      efficient to use the brList... functions provided in CoAxiom than
      always to convert. The use of these functions does not wander far
      from the core CoAxiom/FamInst logic.
      BranchLists are motivated and explained in the note [Branched axioms] in
      - The CoAxiom type has changed significantly. You can see the new
        type in CoAxiom.lhs. It uses a CoAxBranch type to track
        branches of the CoAxiom. Correspondingly various functions
        producing and consuming CoAxioms had to change, including the
        binary layout of interface files.
      - To get branched axioms to work correctly, it is important to have a
        of type "apartness": two types are apart if they cannot unify, and no
        substitution of variables can ever get them to unify, even after type
        simplification. (This is different than the normal failure to unify
        of the type family bit.) This notion in encoded in tcApartTys, in
        Because apartness is finer-grained than unification, the tcUnifyTys
        calls tcApartTys.
      - CoreLinting axioms has been updated, both to reflect the new
        form of CoAxiom and to enforce the apartness rules of branch
        application. The formalization of the new rules is in
      - The FamInst type (in types/FamInstEnv.lhs) has changed
        significantly, paralleling the changes to CoAxiom. Of course,
        this forced minor changes in many files.
      - There are several new Notes in FamInstEnv.lhs, including one
        discussing confluent overlap and why we're not doing it.
      - lookupFamInstEnv, lookupFamInstEnvConflicts, and
        lookup_fam_inst_env' (the function that actually does the work)
        have all been more-or-less completely rewritten. There is a
        Note [lookup_fam_inst_env' implementation] describing the
        implementation. One of the changes that affects other files is
        to change the type of matches from a pair of (FamInst, [Type])
        to a new datatype (which now includes the index of the matching
        branch). This seemed a better design.
      - The TySynInstD constructor in Template Haskell was updated to
        use the new datatype TySynEqn. I also bumped the TH version
        number, requiring changes to DPH cabal files. (That's why the
        DPH repo has an overlapping-tyfams branch.)
      - As SPJ requested, I refactored some of the code in HsDecls:
       * splitting up TyDecl into SynDecl and DataDecl, correspondingly
         changing HsTyDefn to HsDataDefn (with only one constructor)
       * splitting FamInstD into TyFamInstD and DataFamInstD and
         splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl
       * making the ClsInstD take a ClsInstDecl, for parallelism with
         InstDecl's other constructors
       * changing constructor TyFamily into FamDecl
       * creating a FamilyDecl type that stores the details for a family
         declaration; this is useful because FamilyDecls can appear in classes
         other decls cannot
       * restricting the associated types and associated type defaults for a
       * class
         to be the new, more restrictive types
       * splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts,
         according to the new types
       * perhaps one or two more that I'm overlooking
      None of these changes has far-reaching implications.
      - The user manual, section, is updated to describe the new type
  20. 08 Dec, 2012 1 commit
  21. 05 Dec, 2012 1 commit
  22. 26 Nov, 2012 1 commit
    • Simon Peyton Jones's avatar
      Accurately report usage of newtype data constructors in FFI declarations · c8f4f509
      Simon Peyton Jones authored
      See Note [Newtype constructor usage in foreign declarations] in TcForeign.
      It's quite non-trivial to say which newtype constructor are used in
      foreign import/export declarations, and I had to do a bit of refactoring
      to achieve it.  (Say hello to the X5 bus from Oxford to Cambridge.)
      It's a bit tiresome, with some more plumbing, but not hard.
      Trac #7048 triggered this change.
  23. 21 Nov, 2012 2 commits
  24. 07 Nov, 2012 1 commit
  25. 02 Nov, 2012 2 commits
  26. 26 Oct, 2012 1 commit
  27. 04 Oct, 2012 1 commit
  28. 28 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of kind errors · 9a058b17
      Simon Peyton Jones authored
      * Treat kind-equality constraints as *derived* equalities,
        with no evidence.  That is really what they are at the moment.
      * Get rid of EvKindCast and friends.
      * Postpone kind errors properly to the constraint solver
        (lots of small knock-on effects)
      I moved SwapFlag to BasicTypes as well