1. 21 May, 2018 1 commit
    • Ben Gamari's avatar
      ghc-prim: Bump version · e1fd9461
      Ben Gamari authored
      unpackClosure#'s behavior and type has changed. This caused a CPP guard
      in the new ghc-heap package to fail when bootstrapping with GHC 8.4.
      
      Test Plan: Validate bootstrapping with GHC 8.4
      
      Reviewers: RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4716
      e1fd9461
  2. 20 May, 2018 1 commit
  3. 16 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15039 by pretty-printing equalities more systematically · 99f8cc84
      Ryan Scott authored
      GHC previously had a handful of special cases for
      pretty-printing equalities in a more user-friendly manner, but they
      were far from comprehensive (see #15039 for an example of where this
      fell apart).
      
      This patch makes the pretty-printing of equalities much more
      systematic. I've adopted the approach laid out in
      https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated
      `Note [Equality predicates in IfaceType]` accordingly. We are now
      more careful to respect the properties of the
      `-fprint-explicit-kinds` and `-fprint-equality-relations` flags,
      which led to some improvements in error message outputs.
      
      Along the way, I also tweaked the error-reporting machinery not to
      print out the type of a typed hole when the type is an unlifted
      equality, since it's kind (`TYPE ('TupleRep '[])`) was more
      confusing than anything.
      
      Test Plan: make test TEST="T15039a T15039b T15039c T15039d"
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15039
      
      Differential Revision: https://phabricator.haskell.org/D4696
      99f8cc84
  4. 05 May, 2018 1 commit
    • Sebastian Graf's avatar
      Add 'addWordC#' PrimOp · 6243bba7
      Sebastian Graf authored
      This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
      I found 'plusWord2#' while implementing this, which both lacks
      documentation and has a slightly different specification than
      'addWordC#', which means the generic implementation is unnecessarily
      complex.
      
      While I was at it, I also added lacking meta-information on PrimOps
      and refactored 'subWordC#'s generic implementation to be branchless.
      
      Reviewers: bgamari, simonmar, jrtc27, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: dfeuer, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4592
      6243bba7
  5. 19 Apr, 2018 1 commit
  6. 13 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 · c4814ab6
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      `1.0.2.0`, and updated the changelog accordingly.
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15025
      
      Differential Revision: https://phabricator.haskell.org/D4586
      c4814ab6
  7. 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
      TcErrors.
      
      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
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  8. 23 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      Summary:
      At its core, this patch is a simple tweak that allows a user
      to write:
      
      ```lang=haskell
      deriving instance _ => Eq (Foo a)
      ```
      
      Which is functionally equivalent to:
      
      ```lang=haskell
      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
        result.
      
      * 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
      https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7
      
      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
      affdea82
  9. 01 Feb, 2018 1 commit
  10. 31 Jan, 2018 1 commit
  11. 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.
      1577908f
  12. 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.
      2c2f3cea
  13. 16 Oct, 2017 1 commit
  14. 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
      1b476ab5
    • 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
      again.
      3c74a512
  15. 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
      hole).
      
      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
      1c920832
    • Ben Gamari's avatar
      Bump base to 4.11.0.0 · 063e0b4e
      Ben Gamari authored
      Bumps numerous submodules.
      
      Reviewers: austin, hvr
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3974
      063e0b4e
  16. 04 Sep, 2017 1 commit
  17. 23 Jul, 2017 1 commit
  18. 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.
      ad14efd5
  19. 25 Apr, 2017 1 commit
  20. 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.
      0ae72512
  21. 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.
      65b185d4
  22. 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
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • 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.
      7e96526a
  23. 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.
      3415bcaa
  24. 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`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         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.
      b207b536
  25. 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
      repository.
      
          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
      5d38fb69
  26. 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
      33140f41
  27. 15 Dec, 2016 1 commit
  28. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      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
      499e4382
  29. 29 Nov, 2016 1 commit
    • Sylvain Henry's avatar
      Replace -fshow-source-paths with -fhide-source-paths · 3ec85630
      Sylvain Henry authored
      This patch reverts the change introduced with
      587dcccf and restores the previous
      default output of GHC (i.e., show source path and object path for each
      compiled module).
      
      The -fhide-source-paths flag can be used to hide these paths and reduce
      the line
      noise.
      
      Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr
      
      Reviewed By: hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2728
      
      GHC Trac Issues: #12851
      3ec85630
  30. 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
      1bfff60f
    • Simon Peyton Jones's avatar
      Test Trac #12845 · 83a952d1
      Simon Peyton Jones authored
      83a952d1
    • 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.
      1eec1f21
  31. 12 Nov, 2016 1 commit
  32. 05 Nov, 2016 1 commit
  33. 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
         refactoring.
      
      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
         better.
      
      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
         correct.
      
      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
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
  34. 30 Aug, 2016 1 commit
  35. 26 Aug, 2016 1 commit