1. 19 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Allow visible type application for [] · c9e4c861
      Ryan Scott authored
      This amounts to a one-line change in `tcExpr`. I've added a Note to
      explain what is going on.
      
      This requires a separate change in the pattern-match checker to
      account for the fact that typechecked `[]` expressions become
      `ConLikeOut`s, not `ExplicitList`s.
      
      Test Plan: make test TEST=T13680
      
      Reviewers: goldfire, mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie, goldfire
      
      GHC Trac Issues: #13680
      
      Differential Revision: https://phabricator.haskell.org/D3733
      c9e4c861
  2. 29 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix lexically-scoped type variables · 3b0e7555
      Simon Peyton Jones authored
      Trac #13881 showed that our handling of lexically scoped type
      variables was way off when we bring into scope a name 'y' for
      a pre-existing type variable 'a', perhaps with an entirely
      different name.
      
      This patch fixes it; see TcHsType
        Note [Pattern signature binders]
      3b0e7555
  3. 28 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix constraint solving for forall-types · fae672f6
      Simon Peyton Jones authored
      Trac #13879 showed that when we were trying to solve
      
        (forall z1 (y1::z1). ty1)  ~  (forall z2 (y2:z2). ty2)
      
      we'd end up spitting out z1~z2 with no binding site for them.
      Those kind equalities need to be inside the implication.
      
      I ended up re-factoring the code for solving forall-equalities.
      It's quite nice now.
      fae672f6
  4. 27 Jun, 2017 3 commits
  5. 19 Jun, 2017 1 commit
  6. 16 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix the treatment of 'closed' definitions · dc8e6861
      Simon Peyton Jones authored
      The IdBindingInfo field of ATcId serves two purposes
      
      - to control generalisation when we have -XMonoLocalBinds
      - to check for floatability when dealing with (static e)
      
      These are related, but not the same, and they'd becomme confused.
      Trac #13804 showed this up via an example like this:
      
        f periph = let sr :: forall a. [a] -> [a]
                       sr = if periph then reverse else id
      
                       sr2 = sr
                       -- The question: is sr2 generalised?
                       -- It should be, because sr has a type sig
                       -- even though it has periph free
                   in
                   (sr2 [True], sr2 "c")
      
      Here sr2 should be generalised, despite the free var 'periph'
      in 'sr' because 'sr' has a closed type signature.
      
      I documented all this very carefully this time, in TcRnTypes:
        Note [Meaning of IdBindingInfo]
        Note [Bindings with closed types: ClosedTypeId]
      dc8e6861
  7. 05 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Make the MR warning more accurage · a65dfea5
      Simon Peyton Jones authored
      Trac #13785 showed that we were emitting monomorphism warnings
      when we shouldn't.  The fix turned out to be simple.
      
      In fact test T10935 then turned out to be another example of
      the over-noisy warning so I changed the test slightly.
      a65dfea5
  8. 11 May, 2017 2 commits
  9. 06 May, 2017 1 commit
  10. 03 May, 2017 2 commits
  11. 28 Apr, 2017 1 commit
  12. 24 Apr, 2017 1 commit
    • Ryan Scott's avatar
      Add regression test for #13603 · ab27fdcf
      Ryan Scott authored
      Summary:
      Commit b207b536 (#11714) happened to
      fix #13603 as well. Let's add a regression test so that it stays fixed.
      
      Test Plan: make test TEST=T13603
      
      Reviewers: bgamari, austin, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13603
      
      Differential Revision: https://phabricator.haskell.org/D3489
      ab27fdcf
  13. 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
  14. 06 Apr, 2017 2 commits
    • 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
    • Simon Peyton Jones's avatar
      Yet another attempt at inferring the right quantification · bac95f9d
      Simon Peyton Jones authored
      TcSimplify.decideQuantification is truly a tricky function!
      Trac #13509 showed that we were being over-eager with defaulting
      of runtime-rep variables (levity polymorphism), which meant that
      a program was wrongly rejected, and with a very odd error message
      (c.f. Trac #13530)
      
      I spent an unreasonably long time figuring out how to fix this
      in a decent way, and ended up with a major refactoring of
      decideQuantification, with a kock-on effect in simplifyInfer.
      
      It is at least a bit more comprehensible now; but I still
      can't say I like it.
      bac95f9d
  15. 05 Apr, 2017 1 commit
  16. 01 Apr, 2017 1 commit
  17. 29 Mar, 2017 1 commit
    • Matthías Páll Gissurarson's avatar
      Show valid substitutions for typed holes · 26c95f46
      Matthías Páll Gissurarson authored
      The idea is to implement a mechanism similar to PureScript, where they
      suggest which identifiers in scope would fit the given hole. In
      PureScript, they use subsumption (which is what we would like here as
      well). For subsumption, we would have to check each type in scope
      whether the hole is a subtype of the given type, but that would require
      `tcSubType` and constraint satisfiability checking. Currently,
      `TcSimplify` uses a lot of functions from `TcErrors`, so that would
      require more of a rewrite, I will hold on with that for now, and submit
      the more simpler type equality version.
      
      As an example, consider
      
      ```
      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 a stmt of a 'do' block: _ "hello, world"
            In the expression:
              do _ "hello, world"
          • Relevant bindings include
              main :: IO () (bound at test.hs:13:1)
              ps :: String -> IO () (bound at test.hs:7:1)
              ps2 :: forall a. a  -> IO () (bound at test.hs:10:1)
            Valid substitutions include
              putStrLn :: String
                          -> IO () (imported from ‘Prelude’ at
      test.hs:1:1-14
                                    (and originally defined in
      ‘System.IO’))
              putStr :: String
                        -> IO () (imported from ‘Prelude’ at
      test.hs:1:1-14
                                  (and originally defined in ‘System.IO’))
      ```
      
      We'd like here for ps2 to be suggested as well, but for that we require
      subsumption.
      
      Reviewers: austin, bgamari, dfeuer, mpickering
      
      Reviewed By: dfeuer, mpickering
      
      Subscribers: mpickering, Wizek, dfeuer, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3361
      26c95f46
  18. 28 Mar, 2017 1 commit
  19. 27 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13458 · cea71418
      Richard Eisenberg authored
      Core Lint shouldn't check representations of types that don't
      have representations.
      
      test case: typecheck/should_compile/T13458
      cea71418
  20. 17 Mar, 2017 1 commit
  21. 14 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13337. · e0c433c8
      Richard Eisenberg authored
      The big change is the introduction of solveSomeEqualities. This
      is just like solveEqualities, but it doesn't fail if there are unsolved
      equalities when it's all done. Anything unsolved is re-emitted. This
      is appropriate if we are not kind-generalizing, so this new form
      is used when decideKindGeneralizationPlan says not to.
      
      We initially thought that any use of solveEqualities would be tied
      to kind generalization, but this isn't true. For example, we need
      to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which
      is really desugaring). These equalities are all surely going to be
      soluble (if they weren't the "kc" pass would fail), but we still
      need to solve them again. Perhaps if the "kc" pass produced type-
      checked output that is then desugared, solveEqualities really would
      be tied only to kind generalization.
      
      Updates haddock submodule.
      
      Test Plan: ./validate, typecheck/should_compile/T13337
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3315
      e0c433c8
  22. 10 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix constraint simplification in rules · af6ed4a6
      Simon Peyton Jones authored
      Trac #13381 showed that we were losing track of a wanted constraint
      when simplifying the LHS constraints for a RULE.
      
      This patch fixes it, makes the code a bit simpler, and better
      documented.
      af6ed4a6
  23. 02 Mar, 2017 1 commit
    • Edward Z. Yang's avatar
      Properly represent abstract classes in Class and IfaceDecl · fb5cd9d6
      Edward Z. Yang authored
      
      
      Summary:
      Previously, abstract classes looked very much like normal
      classes, except that they happened to have no methods,
      superclasses or ATs, and they came from boot files.  This
      patch gives abstract classes a proper representation in
      Class and IfaceDecl, by moving the things which are never
      defined for abstract classes into ClassBody/IfaceClassBody.
      
      Because Class is abstract, this change had ~no disruption
      to any of the code in GHC; if you ask about the methods of
      an abstract class, we'll just give you an empty list.
      
      This also fixes a bug where abstract type classes were incorrectly
      treated as representationally injective (they're not!)
      
      Fixes #13347, and a TODO in the code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3236
      fb5cd9d6
  24. 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
  25. 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
  26. 14 Feb, 2017 1 commit
    • vivid-synth's avatar
      Allow type defaulting for multi-param type classes with ExtendedDefaultRules · c3bbd1af
      vivid-synth authored
      Expressions like the following will now typecheck:
      
      ```
          data A x = A deriving Show
      
          class ToA a x where
             toA :: a -> A x
      
          instance ToA Integer x where
             toA _ = A
      
          main = print (toA 5 :: A Bool)
      ```
      
      The new defaulting rules are
      
      Find all the unsolved constraints. Then:
      
      * Find those that have exactly one free type variable, and partition
        that subset into groups that share a common type variable `a`.
      * Now default `a` (to one of the types in the default list) if at least
        one of the classes `Ci` is an interactive class
      
      Reviewers: goldfire, bgamari, austin, mpickering, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: mpickering, simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2822
      c3bbd1af
  27. 12 Feb, 2017 1 commit
  28. 09 Feb, 2017 1 commit
  29. 22 Jan, 2017 2 commits
  30. 20 Jan, 2017 1 commit
  31. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  32. 09 Jan, 2017 1 commit
  33. 08 Jan, 2017 1 commit
    • Ömer Sinan Ağacan's avatar
      Parse holes as infix operators · 6c869f90
      Ömer Sinan Ağacan authored
      Reported as #13050. Since holes are expressions but not identifiers,
      holes were not allowed in infix operator position. This patch introduces
      a new production in infix operator parser to allow this.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, RyanGlScott, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2910
      
      GHC Trac Issues: #13050
      6c869f90
  34. 18 Dec, 2016 1 commit