1. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  2. 23 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      At its core, this patch is a simple tweak that allows a user
      to write:
      deriving instance _ => Eq (Foo a)
      Which is functionally equivalent to:
      data Foo a = ...
        deriving Eq
      But with the added flexibility that `StandaloneDeriving` gives you
      (namely, the ability to use it anywhere, not just in the same module
      that `Foo` was declared in). This fixes #13324, and should hopefully
      address a use case brought up in #10607.
      Currently, only the use of a single, extra-constraints wildcard is
      permitted in a standalone deriving declaration. Any other wildcard
      is rejected, so things like
      `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.
      There are quite a few knock-on changes brought on by this change:
      * The `HsSyn` type used to represent standalone-derived instances
        was previously `LHsSigType`, which isn't sufficient to hold
        wildcard types. This needed to be changed to `LHsSigWcType` as a
      * Previously, `DerivContext` was a simple type synonym for
        `Maybe ThetaType`, under the assumption that you'd only ever be in
        the `Nothing` case if you were in a `deriving` clause. After this
        patch, that assumption no longer holds true, as you can also be
        in this situation with standalone deriving when an
        extra-constraints wildcard is used.
        As a result, I changed `DerivContext` to be a proper datatype that
        reflects the new wrinkle that this patch adds, and plumbed this
        through the relevant parts of `TcDeriv` and friends.
      * Relatedly, the error-reporting machinery in `TcErrors` also assumed
        that if you have any unsolved constraints in a derived instance,
        then you should be able to fix it by switching over to standalone
        deriving. This was always sound advice before, but with this new
        feature, it's possible to have unsolved constraints even when
        you're standalone-deriving something!
        To rectify this, I tweaked some constructors of `CtOrigin` a bit
        to reflect this new subtlety.
      This requires updating the Haddock submodule. See my fork at
      Test Plan: ./validate
      Reviewers: simonpj, goldfire, bgamari
      Reviewed By: simonpj
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      GHC Trac Issues: #13324
      Differential Revision: https://phabricator.haskell.org/D4383
  3. 01 Feb, 2018 1 commit
  4. 31 Jan, 2018 1 commit
  5. 09 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix two more bugs in partial signatures · 1577908f
      Simon Peyton Jones authored
      These were shown up by Trac #14643
      Bug 1: if we had a single partial signature for
      two functions
         f, g :: forall a. _ -> a
      then we made two different SigTvs but with the sane Name.
      This was jolly confusing and ultimately led to deeply bogus
      results with Any's appearing in the resulting program. Yikes.
      Fix: clone the quantified variables in TcSigs.tcInstSig (as
      indeed its name suggests).
      Bug 2: we were not eliminating duplicate/superclass constraints
      in the partial signatures of a mutually recursive group.
      Easy to fix: we are already doing dup/superclass elim in
      TcSimplify.decideQuantification.  So we move the partial-sig
      constraints there too.
  6. 08 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Minimise provided dictionaries in pattern synonyms · 2c2f3cea
      Simon Peyton Jones authored
      Trac #14394 showed that it's possible to get redundant
      constraints in the inferred provided constraints of a pattern
      synonym.  This patch removes the redundancy with mkMinimalBySCs.
      To do this I had to generalise the type of mkMinimalBySCs slightly.
      And, to reduce confusing reversal, I made it stable: it now returns
      its result in the same order as its input.  That led to a raft of
      error message wibbles, mostly for the better.
  7. 16 Oct, 2017 1 commit
  8. 25 Sep, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve type-error reporting · 1b476ab5
      Simon Peyton Jones authored
      This patch does two things:
      * When reporting a hole, we now include its kind if the
        kind is not just '*'.  This addresses Trac #14265
      * When reporting things like "'a' is a rigid type varaible
        bound by ...", this patch arranges to group the type variables
        together, so we don't repeat the "bound by..." stuff endlessly
    • Simon Peyton Jones's avatar
      Deal with large extra-contraints wildcards · 3c74a512
      Simon Peyton Jones authored
      For reasons explained in TcHsType
      Note [Extra-constraint holes in partial type signatures],
      if we had
        f :: (_) => blahs
      and the '_' was filled in by more than a 62-tuple of contraints,
      GHC crashed.
      The same Note explains the hacky solution I have adopted to
      evade this.  Maybe there is some better way, but I couldn't
      see one that didn't involve a great deal of work. And the problem
      is a very narrow one!  If the hack bites us we'll need to think
  9. 21 Sep, 2017 2 commits
    • Matthías Páll Gissurarson's avatar
      Also show types that subsume a hole as valid substitutions for that hole. · 1c920832
      Matthías Páll Gissurarson authored
      This builds on the previous "Valid substitutions include..." functionality,
      but add subsumption checking as well, so that the suggested valid substitutions
      show not only exact matches, but also identifiers that fit the hole by virtue of
      subsuming the type of the hole (i.e. being more general than the type of the
      Building on the previous example, in the given program
      ps :: String -> IO ()
      ps = putStrLn
      ps2 :: a -> IO ()
      ps2 _ = putStrLn "hello, world"
      main :: IO ()
      main = _ "hello, world"
      The results would be something like
          • Found hole: _ :: [Char] -> IO ()
          • In the expression: _
            In the expression: _ "hello, world"
            In an equation for ‘main’: main = _ "hello, world"
          • Relevant bindings include main :: IO () (bound at t1.hs:8:1)
            Valid substitutions include
              ps :: String -> IO () (defined at t1.hs:2:1)
              ps2 :: forall a. a -> IO () (defined at t1.hs:5:1)
              putStrLn :: String -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              fail :: forall (m :: * -> *). Monad m => forall a. String -> m a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              mempty :: forall a. Monoid a => a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              print :: forall a. Show a => a -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              (Some substitutions suppressed;
               use -fmax-valid-substitutions=N or -fno-max-valid-substitutions)
      Signed-off-by: Matthías Páll Gissurarson's avatarMatthías Páll Gissurarson <mpg@mpg.is>
      Modified according to suggestions from Simon PJ
      Accept tests that match the expectations, still a few to look better at
      Swithced to using tcLookup, after sit down with SPJ at ICFP. Implications are WIP.
      Now works with polymorphism and constraints!
      We still need to merge the latest master, before we can make a patch.
      Wrap the type of the hole, instead of implication shenanigans,
      As per SPJs suggestion, this is simpler and feels closer to
      what we actually want to do.
      Updated tests with the new implementation
      Remove debugging trace and update documentation
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: RyanGlScott, rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3930
    • Ben Gamari's avatar
      Bump base to · 063e0b4e
      Ben Gamari authored
      Bumps numerous submodules.
      Reviewers: austin, hvr
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3974
  10. 04 Sep, 2017 1 commit
  11. 23 Jul, 2017 1 commit
  12. 26 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Some tidying up of type pretty-printing · ad14efd5
      Simon Peyton Jones authored
      Triggered by the changes in #13677, I ended up doing a bit of
      refactoring in type pretty-printing.
      * We were using TyOpPrec and FunPrec rather inconsitently, so
        I made it consisent.
      * That exposed the fact that we were a bit undecided about whether
        to print
           a + b -> c + d   vs   (a+b) -> (c+d)
        and similarly
           a ~ [b] => blah  vs   (a ~ [b]) => blah
        I decided to make TyOpPrec and FunPrec compare equal
        (in BasicTypes), so (->) is treated as equal precedence with
        other type operators, so you get the unambiguous forms above,
        even though they have more parens.
        We could readily reverse this decision.
        See Note [Type operator precedence] in BasicTypes
      * I fixed a bug in pretty-printing of HsType where some
        parens were omitted by mistake.
  13. 25 Apr, 2017 1 commit
  14. 13 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Yet more work on TcSimplify.simplifyInfer · 0ae72512
      Simon Peyton Jones authored
      The proximate cause for this patch is Trac #13482, which pointed out
      further subtle interactions between
         - Inferring the most general type of a function
         - A partial type signature for that function
      That led me into /further/ changes to the shiny new stuff in
      TcSimplify.simplifyInfer, decideQuantification, decideMonoTyVars,
      and related functions.
      Happily, I was able to make some of it quite a bit simpler,
      notably the bit about promoting free tyvars.  I'm happy with
      the result.
      Moreover I fixed Trac #13524 at the same time.  Happy days.
  15. 06 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Be less aggressive about fragile-context warrnings · 65b185d4
      Simon Peyton Jones authored
      In the implementation of WarnSimplifiableClassConstraints, be
      less aggressive about reporting a problem. We were complaining
      about a "fragile" case that in fact was not fragile.
      See Note [Simplifiable given constraints] in TcValidity.
      This fixes Trac #13526.
  16. 10 Mar, 2017 2 commits
    • 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!
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      All this led to Trac #13371 and Trac #13393.
      This commit tidies it all up:
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      In doing all this I also made UniqDFM behave a little more nicely:
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      I may not have associated all of them with the correct commit.
  17. 26 Feb, 2017 1 commit
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
  18. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      This involves a few things,
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
       * Unsaturated applications of `(->)` are expressed as explicit
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
         of `(->)` with the appropriate `RuntimeRep` arguments
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      Also, this introduces two known regressions,
      `tcfail181`, `T10403`
      Only shows the instance,
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      T5963 (Typeable)
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      Haddock performance
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
  19. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      Tests containing inline comments or multiline strings are not modified.
      Preparation for #12223.
      Test Plan: Harbormaster
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      Reviewed By: mpickering
      Subscribers: mpickering
      Differential Revision: https://phabricator.haskell.org/D3000
      GHC Trac Issues: #12223
  20. 20 Jan, 2017 1 commit
    • Phil de Joux's avatar
      Show explicit quantifiers in conflicting definitions error · 33140f41
      Phil de Joux authored
      This fixes #12441, where definitions in a Haskell module and its boot
      file which differed only in their quantifiers produced a confusing error
      message. Here we teach GHC to always show quantifiers for these errors.
      Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: snowleopard, simonpj, mpickering, thomie
      Differential Revision: https://phabricator.haskell.org/D2734
      GHC Trac Issues: #12441
  21. 15 Dec, 2016 1 commit
  22. 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 they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      Test Plan: ./validate
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      Reviewed By: simonpj, bgamari
      Subscribers: simonpj, goldfire, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D2752
      GHC Trac Issues: #3384
  23. 29 Nov, 2016 1 commit
  24. 25 Nov, 2016 3 commits
    • Simon Peyton Jones's avatar
      Fix inference of partial signatures · 1bfff60f
      Simon Peyton Jones authored
      When we had
        f :: ( _ ) => blah
      we were failing to call growThetaTyVars, as we do in the
      no-type-signature case, and that meant that we weren't generalising
      over the right type variables.  I'm quite surprised this didn't cause
      problems earlier.
      Anyway Trac #12844 showed it up and this patch fixes it
    • Simon Peyton Jones's avatar
      Test Trac #12845 · 83a952d1
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
        Trac #12526
        Trac #12444
        Trac #12538
      The main changes are these
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
        See TcSMonad Note [The improvement story and derived shadows]
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      I also did lots of work on comments, including fixing Trac #12821.
  25. 12 Nov, 2016 1 commit
  26. 05 Nov, 2016 1 commit
  27. 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
  28. 30 Aug, 2016 1 commit
  29. 26 Aug, 2016 1 commit
  30. 17 Aug, 2016 1 commit
  31. 14 Jul, 2016 1 commit
  32. 28 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Don't omit any evidence bindings · af21e388
      Simon Peyton Jones authored
      This fixes Trac #12156, where we were omitting to make an
      evidence binding (because cec_suppress was on), but yet the
      program was compiled and run.
      The fix is easy, and involves deleting code :-).
  33. 23 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Narrow the warning for simplifiable constraints · 643706e4
      Simon Peyton Jones authored
      In Trac #11948 I added the warning
      which warns if the class constraints in a type signature are
      But in fact the fragility it warns about only happens with
      NoMonoLocalBinds, so this patch switches off the warning if
      you have MonoLocalBinds (and suggests using it in the error
      See Note [Simplifiable given constraints] in TcValidity.
  34. 20 Jun, 2016 1 commit
  35. 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.