1. 30 Sep, 2016 2 commits
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 66a8c194
      Simon Peyton Jones authored
      1. Trac #12593 exposed a long-standing bug in the occurs
         checking machinery.  When unifying two type variables
                a ~ b
         where a /= b, we were assuming that there could be
         no occurs-check error.  But there can: 'a' can occur
         in b's kind!  When the RHS was a non-tyvar we used
         occurCheckExpand, which /did/ look in kinds, but not
         when the RHS was a tyvar.
      
         This bug has been lurking ever since TypeInType, maybe
         longer.  And it was present both in TcUnify (the on-the-fly
         unifier), and in TcInteract.
      
         I ended up refactoring both so that the tyvar/tyvar
         path naturally goes through the same occurs-check as
         non-tyvar rhss.  It's simpler and more robust now.
      
         One good thing is that both unifiers now share
             TcType.swapOverVars
             TcType.canSolveByUnification
         previously they had different logic for the same goals
      
      2. Fixing this bug exposed another!  In T11635 we end
         up unifying
         (alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
         Now that the occurs check is done for tyvars too, we
         look inside beta's kind.  And then reject the program
         becuase of the forall inside there.  But in fact that
         forall is fine -- it does not count as impredicative
         polymoprhism.   See Note [Checking for foralls]
         in TcType.
      
      3. All this fuss around occurrence checking forced me
         to look at TcUnify.checkTauTvUpdate
                and TcType.occurCheckExpand
         There's a lot of duplication there, and I managed
         to elminate quite a bit of it. For example,
         checkTauTvUpdate called a local 'defer_me'; and then
         called occurCheckExpand, which then used a very
         similar 'fast_check'.
      
         Things are better, but there is more to do.
      66a8c194
  2. 15 Jun, 2016 2 commits
    • 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:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           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
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        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.
      e368f326
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  3. 28 Apr, 2016 1 commit
  4. 31 Mar, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make SigSkol take TcType not ExpType · 0ad2021b
      Simon Peyton Jones authored
      For some reason a SigSkol had an ExpType in it, and there were
      lots of places where we needed it to have a TcType.  And was indeed
      always a Check.  All a lot of fuss about nothing.
      
      Delete code, fewer failure points, types are more precise.
      All good.
      0ad2021b
  5. 21 Mar, 2016 1 commit
  6. 16 Mar, 2016 1 commit
  7. 15 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Allow eager unification with type families. · 3f5d1a13
      eir@cis.upenn.edu authored
      Previously, checkTauTvUpdate, used in the eager unifier (TcUnify)
      right before writing to a metavar, refused to write a metavar to
      a type involving type functions. The reason for this was given
      in a Note, but the Note didn't make all that much sense and even
      admitted that it was a bit confused. The Note, in turn, referred
      to another Note, which it was quite sceptical of, as well.
      
      The type-family check was slowing down performance, so I tried
      removing it, running the tests referred to in the Note. The tests
      all passed without the check. Looking at more test results, I
      saw several error messages improve without the check, and some cases
      where GHC looped (T7788, in particular) it now doesn't.
      
      So, all in all, quite a win: Two hairy Notes removed, several lines
      of code removed, better performance, and improved output.
      
      [skip ci]
      3f5d1a13
    • eir@cis.upenn.edu's avatar
      Fix #11407. · e9bf7bb5
      eir@cis.upenn.edu authored
      This removes the `defer_me` check that was in checkTauTvUpdate
      and uses only a type family check instead. The old defer_me check
      repeated work done by fast_check in occurCheckExpand.
      
      There is also some error message improvement, necessitated by
      the terrible error message that the test case produced, even when
      it didn't consume all of memory.
      
      test case: dependent/should_fail/T11407
      
      [skip ci]
      e9bf7bb5
  8. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  9. 08 Feb, 2016 1 commit
  10. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  11. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  12. 15 Jan, 2016 1 commit
  13. 30 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11305. · c06b46d0
      eir@cis.upenn.edu authored
      Summary:
      In the fallthrough case when doing a subsumption case, we
      need to deeply instantiate to remove any buried foralls in
      the "actual" type.
      
      Once this validates, please feel free to commit it; I may not
      have the chance to do this on Tuesday. Back in full action on
      Wed.
      
      Test Plan: ./validate, typecheck/should_compiler/T11305
      
      Reviewers: austin, bgamari, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1715
      
      GHC Trac Issues: #11305
      c06b46d0
  14. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  15. 22 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix typechecking for pattern synonym signatures · f40e122b
      Simon Peyton Jones authored
      Various tickets have revealed bad shortcomings in the typechecking of
      pattern type synonyms.  Discussed a lot in (the latter part of)
      Trac #11224.
      
      This patch fixes the most complex issues:
      
      - Both parser and renamer now treat pattern synonyms as an
        ordinary LHsSigType.  Nothing special.  Hooray.
      
      - tcPatSynSig (now in TcPatSyn) typechecks the signature, and
        decomposes it into its pieces.
        See Note [Pattern synonym signatures]
      
      - tcCheckPatSyn has had a lot of refactoring.
        See Note [Checking against a pattern signature]
      
      The result is a lot tidier and more comprehensible.
      Plus, it actually works!
      
      NB: this patch doesn't actually address the precise
          target of #11224, namely "inlining pattern synonym
          does not preserve semantics".  That's an unrelated
          bug, with a separate patch.
      
      ToDo: better documentation in the user manual
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, mpickering, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1685
      
      GHC Trac Issues: #11224
      f40e122b
  16. 16 Dec, 2015 1 commit
  17. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  18. 07 Dec, 2015 1 commit
  19. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  20. 27 Oct, 2015 1 commit
  21. 05 Oct, 2015 1 commit
  22. 26 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Use a Representaional coercion for data families · ff8a6716
      Simon Peyton Jones authored
      When we have
        data instance T (a,b) = MkT a b
      we make a represntation type
        data TPair a b = MkT a b
      plus an axiom to connect the two
        ax a b :: T (a,b)  ~R  TPair a b
      
      Previously this was a Nominal equality, and that worked ok
      but seems illogical since Nominal equalities are between
      types that the programmer thinks of as being equal.  But
      TPair is not visible to the programmer; indeed we call it
      the "representation TyCon".  So a Representational equality
      seems more suitable here.
      ff8a6716
  23. 18 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Rename getCtLoc, setCtLoc · 4a7a6c3a
      Simon Peyton Jones authored
      getCtLoc -> getCtLocM
      setCtLoc -> setCtLocM
      
      These operations are monadic, and I want to introduce a
      pure version of setCtLoc :: Ct -> CtLoc -> Ct
      4a7a6c3a
  24. 16 Jun, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor handling of decomposition. · 7eceffb3
      eir@cis.upenn.edu authored
      This adds the significant Note [Decomposing equalities] to
      TcCanonical, trying to sort out the various cases involved.
      
      The only functional change this commit should make is a different
      treatment of data families, which were wrong before (they could
      be decomposed at role R, which is wrong).
      7eceffb3
  25. 07 Apr, 2015 1 commit
  26. 04 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      Check for equality before deferring · 3aa2519e
      Simon Peyton Jones authored
      This one was a bit of a surprise. In fixing Trac #7854, I moved
      the checkAmbiguity tests to checkValidType. That meant it happened
      even for monotypes, and that turned out to be very expensive in
      T9872a, for reasons described in this (new) Note in TcUnify:
      
          Note [Check for equality before deferring]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Particularly in ambiguity checks we can get equalities like (ty ~ ty).
          If ty involves a type function we may defer, which isn't very sensible.
          An egregious example of this was in test T9872a, which has a type signature
                 Proxy :: Proxy (Solutions Cubes)
          Doing the ambiguity check on this signature generates the equality
             Solutions Cubes ~ Solutions Cubes
          and currently the constraint solver normalises both sides at vast cost.
          This little short-cut in 'defer' helps quite a bit.
      
      I fixed the problem with a quick equality test, but it feels like an ad-hoc
      solution; I think we might want to do something in the constraint solver too.
      
      (The problem was there all along, just more hidden.)
      3aa2519e
  27. 12 Feb, 2015 1 commit
  28. 11 Feb, 2015 2 commits
  29. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Major patch to add -fwarn-redundant-constraints · 32973bf3
      Simon Peyton Jones authored
      The idea was promted by Trac #9939, but it was Christmas, so I did
      some recreational programming that went much further.
      
      The idea is to warn when a constraint in a user-supplied context is
      redundant.  Everything is described in detail in
        Note [Tracking redundant constraints]
      in TcSimplify.
      
      Main changes:
      
       * The new ic_status field in an implication, of type ImplicStatus.
         It replaces ic_insol, and includes information about redundant
         constraints.
      
       * New function TcSimplify.setImplicationStatus sets the ic_status.
      
       * TcSigInfo has sig_report_redundant field to say whenther a
         redundant constraint should be reported; and similarly
         the FunSigCtxt constructor of UserTypeCtxt
      
       * EvBinds has a field eb_is_given, to record whether it is a given
         or wanted binding. Some consequential chagnes to creating an evidence
         binding (so that we record whether it is given or wanted).
      
       * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
         see Note [Typechecking plan for instance declarations] in
         TcInstDcls
      
       * Some significant changes to the type checking of instance
         declarations; Note [Typechecking plan for instance declarations]
         in TcInstDcls.
      
       * I found that TcErrors.relevantBindings was failing to zonk the
         origin of the constraint it was looking at, and hence failing to
         find some relevant bindings.  Easy to fix, and orthogonal to
         everything else, but hard to disentangle.
      
      Some minor refactorig:
      
       * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
      
       * TcClassDcl and TcInstDcls now have their own code for typechecking
         a method body, rather than sharing a single function. The shared
         function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
         and the differences were growing confusing.
      
       * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
         use it
      
       * Add new function Bag.catBagMaybes, and use it in TcSimplify
      32973bf3
  30. 23 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Eliminate so-called "silent superclass parameters" · a6f0f5ab
      Simon Peyton Jones authored
      The purpose of silent superclass parameters was to solve the
      awkward problem of superclass dictinaries being bound to bottom.
      See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls
      
      Although the silent-superclass idea worked,
      
        * It had non-local consequences, and had effects even in Haddock,
          where we had to discard silent parameters before displaying
          instance declarations
      
        * It had unexpected peformance costs, shown up by Trac #3064 and its
          test case.  In monad-transformer code, when constructing a Monad
          dictionary you had to pass an Applicative dictionary; and to
          construct that you neede a Functor dictionary. Yet these extra
          dictionaries were often never used.  (All this got much worse when
          we added Applicative as a superclass of Monad.) Test T3064
          compiled *far* faster after silent superclasses were eliminated.
      
        * It introduced new bugs.  For example SilentParametersOverlapping,
          T5051, and T7862, all failed to compile because of instance overlap
          directly because of the silent-superclass trick.
      
      So this patch takes a new approach, which I worked out with Dimitrios
      in the closing hours before Christmas.  It is described in detail
      in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls.
      
      Seems to work great!
      
      Quite a bit of knock-on effect
      
       * The main implementation work is in tcSuperClasses in TcInstDcls
         Everything else is fall-out
      
       * IdInfo.DFunId no longer needs its n-silent argument
         * Ditto IDFunId in IfaceSyn
         * Hence interface file format changes
      
       * Now that DFunIds do not have silent superclass parameters, printing
         out instance declarations is simpler. There is tiny knock-on effect
         in Haddock, so that submodule is updated
      
       * I realised that when computing the "size of a dictionary type"
         in TcValidity.sizePred, we should be rather conservative about
         type functions, which can arbitrarily increase the size of a type.
         Hence the new datatype TypeSize, which has a TSBig constructor for
         "arbitrarily big".
      
       * instDFunType moves from TcSMonad to Inst
      
       * Interestingly, CmmNode and CmmExpr both now need a non-silent
         (Ord r) in a couple of instance declarations. These were previously
         silent but must now be explicit.
      
       * Quite a bit of wibbling in error messages
      a6f0f5ab
  31. 12 Dec, 2014 1 commit
  32. 10 Dec, 2014 1 commit
    • Yuras's avatar
      fix misleading error message regarding function arity · 09b79433
      Yuras authored
      Summary:
      The error reports something like:
      
        The function ‘f’ is applied to three arguments,
        but its type ‘Int -> Float -> Char -> Bool’ has only three
      
      The original type was "Monad m => Int -> Float -> m Bool", but
      "m" was unified with "-> Char".
      
      Now it looks better:
      
        The function ‘f’ is applied to three arguments,
        its type is ‘Int -> Float -> m0 Bool’,
        it is specialized to ‘Int -> Float -> Char -> Bool’
      
      Test Plan: T9605
      
      Reviewers: simonpj, austin
      
      Reviewed By: austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D556
      
      GHC Trac Issues: #9605
      09b79433
  33. 03 Dec, 2014 1 commit
  34. 02 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename Untouchables to TcLevel · 26a3d0fe
      Simon Peyton Jones authored
      This is a long-overdue renaming
         Untouchables  -->   TcLevel
      It is renaming only; no change in functionality.
      
      We really wanted to get this done before the 7.10 fork.
      26a3d0fe
  35. 21 Nov, 2014 2 commits