1. 16 Oct, 2017 6 commits
    • Herbert Valerio Riedel's avatar
      Bump ghc-prim to 0.5.2.0 and update changelog · 6cb46421
      Herbert Valerio Riedel authored
      This is prompted by the addition of `compareByteArrays#` in
      e3ba26f8
      
      NOTE: We may switch to synchronise `ghc-prim` with GHC's version at some point
      6cb46421
    • Jessica Clarke's avatar
      RtClosureInspect: Fix inspecting Char# on 64-bit big-endian · d6c33da8
      Jessica Clarke authored
      Char# is represented with a full machine word, whereas Char's Storable
      instance uses an Int32, so we can't just treat it like a single-element
      Char array. Instead, read it as an Int and use chr to turn it into a
      Char. This fixes Trac #11262.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11262
      
      Differential Revision: https://phabricator.haskell.org/D4089
      d6c33da8
    • Edward Z. Yang's avatar
      Levity polymorphic Backpack. · fd8b044e
      Edward Z. Yang authored
      
      
      This patch makes it possible to specify non * kinds of
      abstract data types in signatures, so you can have
      levity polymorphism through Backpack, without the runtime
      representation constraint!
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: andrewthad, bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13955
      
      Differential Revision: https://phabricator.haskell.org/D3825
      fd8b044e
    • Herbert Valerio Riedel's avatar
      Enable testing 'Natural' type in TEST=arith011 · 843772b8
      Herbert Valerio Riedel authored
      This now passes thanks to 5984a698 (re #13203)
      843772b8
    • Herbert Valerio Riedel's avatar
      Implement new `compareByteArrays#` primop · e3ba26f8
      Herbert Valerio Riedel authored
      The new primop
      
          compareByteArrays# :: ByteArray# -> Int# {- offset -}
                             -> ByteArray# -> Int# {- offset -}
                             -> Int# {- length -}
                             -> Int#
      
      allows to compare the subrange of the first `ByteArray#` to
      the (same-length) subrange of the second `ByteArray#` and returns a
      value less than, equal to, or greater than zero if the range is found,
      respectively, to be byte-wise lexicographically less than, to match,
      or be greater than the second range.
      
      Under the hood, the new primop is implemented in terms of the standard
      ISO C `memcmp(3)` function. It is currently an out-of-line primop but
      work is underway to optimise this into an inline primop for a future
      follow-up Differential (see D4091).
      
      This primop has applications in packages like `text`, `text-short`,
      `bytestring`, `text-containers`, `primitive`, etc.  which currently
      have to incur the overhead of an ordinary FFI call to directly or
      indirectly invoke `memcmp(3)` as well has having to deal with some
      `unsafePerformIO`-variant.
      
      While at it, this also improves the documentation for the existing
      `copyByteArray#` primitive which has a non-trivial type-signature
      that significantly benefits from a more explicit description of its
      arguments.
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D4090
      e3ba26f8
    • Herbert Valerio Riedel's avatar
      Fix panic for `ByteArray#` arguments in CApiFFI foreign imports · add85cc2
      Herbert Valerio Riedel authored
      Declarations such as
      
        foreign import capi  unsafe "string.h strlen"
            c_strlen_capi :: ByteArray# -> IO CSize
      
        foreign import capi  unsafe "string.h memset"
            c_memset_capi :: MutableByteArray# s -> CInt -> CSize -> IO ()
      
      would cause GHC to panic because the CApiFFI c-wrapper generator didn't
      know what C type to use for `(Mutable)ByteArray#` types (unlike the
      `ccall` codepath).
      
      This addresses #9274
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D4092
      add85cc2
  2. 12 Oct, 2017 4 commits
    • Simon Peyton Jones's avatar
      Re-apply "Typeable: Allow App to match arrow types" · 3de788c4
      Simon Peyton Jones authored
      This re-applies
       commit cc6be3a2
        Author: Ben Gamari <bgamari.foss@gmail.com>
        Date:   Tue Sep 19 18:57:38 2017 -0400
      
          Typeable: Allow App to match arrow types
      
      which was reverted because of Trac #14270.  Now the latter is
      fixed we can re-apply it.
      
      The original ticket was Trac #14236
      3de788c4
    • Simon Peyton Jones's avatar
      Do not bind coercion variables in SpecConstr rules · fb050a33
      Simon Peyton Jones authored
      Trac #14270 showed that SpecConstr could cause nasty Lint failures
      if it generates a RULE that binds coercion varables.  See
      
       * Note [SpecConstr and casts], and
       * the test simplCore/should_compile/T14270.
      
      This doesn't feel like the final word to me, because somehow the
      specialisation "ought" to work.  So I left in a debug WARN to yell if
      the new check acutally fires.
      
      Meanwhile, it stops the erroneous specialisation.
      
      binding coercion
      fb050a33
    • Simon Peyton Jones's avatar
      Add missing T14325.stderr · 15aefb48
      Simon Peyton Jones authored
      15aefb48
    • Simon Peyton Jones's avatar
      Do not quantify over deriving clauses · 82b77ec3
      Simon Peyton Jones authored
      Trac #14331 showed that in a data type decl like
      
         data D = D deriving (C (a :: k))
      
      we were quantifying D over the 'k' in the deriving clause.  Yikes.
      
      Easily fixed, by deleting code in RnTypes.extractDataDefnKindVars
      
      See the discussion on the ticket, esp comment:8.
      82b77ec3
  3. 11 Oct, 2017 6 commits
    • Simon Peyton Jones's avatar
      Add a missing zonk in TcDerivInfer.simplifyDeriv · 13fdca3d
      Simon Peyton Jones authored
      I'm astonished that anything worked without this!
      
      Fixes Trac #14339
      13fdca3d
    • Simon Peyton Jones's avatar
      Avoid creating dependent types in FloatOut · 4bb54a45
      Simon Peyton Jones authored
      This bug was exposed by Trac #14270.  The problem and its cure
      is described in SetLevels, Note [Floating and kind casts].
      
      It's simple and will affect very few programs.  But the very
      fact that it was so unexpected is discomforting.
      4bb54a45
    • Alan Zimmerman's avatar
      Pretty-printing of derived multi-parameter classes omits parentheses · 6869864e
      Alan Zimmerman authored
      Summary:
      Pretty printing a splice with an HsAppType in the deriving clause, such as
      
          $([d| data Foo a = Foo a deriving (C a) |])
      
      would omit the parens.
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, austin, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14289
      
      Differential Revision: https://phabricator.haskell.org/D4056
      6869864e
    • Ryan Scott's avatar
      Fix #10816 by renaming FixitySigs more consistently · 9c3f7316
      Ryan Scott authored
      Summary:
      #10816 surfaced because we were renaming top-level fixity
      declarations with a different code path (`rnSrcFixityDecl`) than
      the code path for fixity declarations inside of type classes, which
      is not privy to names that exist in the type namespace. Luckily, the
      fix is simple: use `rnSrcFixityDecl` in both places.
      
      Test Plan: make test TEST=T10816
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #10816
      
      Differential Revision: https://phabricator.haskell.org/D4077
      9c3f7316
    • Simon Peyton Jones's avatar
      Remove wc_insol from WantedConstraints · f20cf982
      Simon Peyton Jones authored
      This patch is a pure refactoring, which I've wanted to do for
      some time.  The main payload is
      
      * Remove the wc_insol field from WantedConstraints;
        instead put all the insolubles in wc_simple
      
      * Remove inert_insols from InertCans
        Instead put all the insolubles in inert_irreds
      
      * Add a cc_insol flag to CIrredCan, to record that
        the constraint is definitely insoluble
      
      Reasons
      
      * Quite a bit of code gets slightly simpler
      * Fewer concepts to keep separate
      * Insolubles don't happen at all in production code that is
        just being recompiled, so previously there was a lot of
        moving-about of empty sets
      
      A couple of error messages acutally improved.
      f20cf982
    • Simon Peyton Jones's avatar
      Fix over-eager error suppression in TcErrors · c81f66cc
      Simon Peyton Jones authored
      See Note [Given insolubles] in TcRnTypes
      
      Fixes Trac #14325.
      c81f66cc
  4. 07 Oct, 2017 2 commits
    • Ryan Scott's avatar
      Fix #14320 by looking through HsParTy in more places · f1d2db68
      Ryan Scott authored
      Summary:
      GHC was needlessly rejecting GADT constructors' type
      signatures that were surrounded in parentheses due to the fact that
      `splitLHsForAllTy` and `splitLHsQualTy` (which are used to check as
      part of checking if GADT constructor return types are correct)
      weren't looking through parentheses (i.e., `HsParTy`). This is
      easily fixed, though.
      
      Test Plan: make test TEST=T14320
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14320
      
      Differential Revision: https://phabricator.haskell.org/D4072
      f1d2db68
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      Summary:
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      
      Along the way, I:
      
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
        this.
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      
      Test Plan: make test TEST=T11721_TH
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: goldfire, bgamari, simonpj
      
      Subscribers: rwbarton, thomie, simonpj
      
      GHC Trac Issues: #11721
      
      Differential Revision: https://phabricator.haskell.org/D4070
      341d3a78
  5. 06 Oct, 2017 1 commit
  6. 05 Oct, 2017 2 commits
  7. 03 Oct, 2017 7 commits
    • Edward Z. Yang's avatar
      Include libraries which fill holes as deps when linking. · f3f624ae
      Edward Z. Yang authored
      Fixes the issue reported at https://github.com/haskell/cabal/issues/4755
      
      
      and fixes #14304 in the GHC tracker.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14304
      
      Differential Revision: https://phabricator.haskell.org/D4057
      f3f624ae
    • Iavor S. Diatchki's avatar
      Implement Div, Mod, and Log for type-level nats. · fa8035e3
      Iavor S. Diatchki authored
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, dfeuer, adamgundry, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4002
      fa8035e3
    • Ryan Scott's avatar
      Track the order of user-written tyvars in DataCon · ef26182e
      Ryan Scott authored
      After typechecking a data constructor's type signature, its type
      variables are partitioned into two distinct groups: the universally
      quantified type variables and the existentially quantified type
      variables. Then, when prompted for the type of the data constructor,
      GHC gives this:
      
      ```lang=haskell
      MkT :: forall <univs> <exis>. (...)
      ```
      
      For H98-style datatypes, this is a fine thing to do. But for GADTs,
      this can sometimes produce undesired results with respect to
      `TypeApplications`. For instance, consider this datatype:
      
      ```lang=haskell
      data T a where
        MkT :: forall b a. b -> T a
      ```
      
      Here, the user clearly intended to have `b` be available for visible
      type application before `a`. That is, the user would expect
      `MkT @Int @Char` to be of type `Int -> T Char`, //not//
      `Char -> T Int`. But alas, up until now that was not how GHC
      operated—regardless of the order in which the user actually wrote
      the tyvars, GHC would give `MkT` the type:
      
      ```lang=haskell
      MkT :: forall a b. b -> T a
      ```
      
      Since `a` is universal and `b` is existential. This makes predicting
      what order to use for `TypeApplications` quite annoying, as
      demonstrated in #11721 and #13848.
      
      This patch cures the problem by tracking more carefully the order in
      which a user writes type variables in data constructor type
      signatures, either explicitly (with a `forall`) or implicitly
      (without a `forall`, in which case the order is inferred). This is
      accomplished by adding a new field `dcUserTyVars` to `DataCon`, which
      is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to
      the order in which the user wrote them. For more details, refer to
      `Note [DataCon user type variables]` in `DataCon.hs`.
      
      An interesting consequence of this design is that more data
      constructors require wrappers. This is because the workers always
      expect the first arguments to be the universal tyvars followed by the
      existential tyvars, so when the user writes the tyvars in a different
      order, a wrapper type is needed to swizzle the tyvars around to match
      the order that the worker expects. For more details, refer to
      `Note [Data con wrappers and GADT syntax]` in `MkId.hs`.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: ezyang, goldfire, rwbarton, thomie
      
      GHC Trac Issues: #11721, #13848
      
      Differential Revision: https://phabricator.haskell.org/D3687
      ef26182e
    • Ryan Scott's avatar
      Add regression test for #9725 · a02039c7
      Ryan Scott authored
      Kind equalities saves the day!
      a02039c7
    • Simon Peyton Jones's avatar
      Suppress error cascade in record fields · cb767542
      Simon Peyton Jones authored
      When a record contruction or pattern uses a data constructor
      that isn't in scope, we may produce spurious ambiguous-field
      errors (Trac #14307).  E.g.
      
         f (A { fld = x }) = e
      
      where 'A' is not in scope.  We want to draw attention to the
      out-of-scope data constructor first; once that is fixed we
      can think about the fields.
      
      This patch suppresses the field errors if the data con is out
      of scope.
      cb767542
    • Simon Peyton Jones's avatar
      Fix nasty bug in w/w for absence analysis · dbbee1ba
      Simon Peyton Jones authored
      This dark corner was exposed by Trac #14285.  It involves the
      interaction between absence analysis and INLINABLE pragmas.
      
      There is a full explanation in Note [aBSENT_ERROR_ID] in MkCore,
      which you can read there.  The changes in this patch are
      
      * Make exprIsHNF return True for absentError, treating
        absentError like an honorary data constructor.
      
      * Make absentError /not/ be diverging, unlike other error Ids.
      
      This is all a bit horrible.
      
      * While doing this I found that exprOkForSpeculation didn't
        have a case for value lambdas so I added one.  It's not
        really called on lifted types much, but it seems like the
        right thing
      dbbee1ba
    • Simon Peyton Jones's avatar
      Fix bug in the short-cut solver · a8fde183
      Simon Peyton Jones authored
      Trac #13943 showed that the relatively-new short-cut solver
      for class constraints (aka -fsolve-constant-dicts) was wrong.
      In particular, see "Type families" under Note [Shortcut solving]
      in TcInteract.
      
      The short-cut solver recursively solves sub-goals, but it doesn't
      flatten type-family applications, and as a result it erroneously
      thought that C (F a) cannot possibly match (C 0), which is
      simply untrue.  That led to an inifinte loop in the short-cut
      solver.
      
      The significant change is the one line
      
      +                 , all isTyFamFree preds  -- See "Type families" in
      +                                          -- Note [Shortcut solving]
      
      but, as ever, I do some other refactoring.  (E.g. I changed the
      name of the function to shortCutSolver rather than the more
      generic trySolveFromInstance.)
      
      I also made the short-cut solver respect the solver-depth limit,
      so that if this happens again it won't just produce an infinite
      loop.
      
      A bit of other refactoring, notably moving isTyFamFree
      from TcValidity to TcType
      a8fde183
  8. 02 Oct, 2017 1 commit
  9. 29 Sep, 2017 1 commit
  10. 28 Sep, 2017 1 commit
    • Simon Marlow's avatar
      mkDataConRep: fix bug in strictness signature (#14290) · 5935acdb
      Simon Marlow authored
      The strictness signature for a data con wrapper wasn't including any
      dictionary arguments, which meant that bangs on the fields of a
      constructor with an existential context would be moved to the wrong
      fields.  See T14290 for an example.
      
      Test Plan:
      * New test T14290
      * validate
      
      Reviewers: simonpj, niteria, austin, bgamari, erikd
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14290
      
      Differential Revision: https://phabricator.haskell.org/D4040
      5935acdb
  11. 27 Sep, 2017 2 commits
  12. 26 Sep, 2017 4 commits
  13. 25 Sep, 2017 3 commits
    • Ryan Scott's avatar
      Bump template-haskell to 2.13.0.0 · 3804a7eb
      Ryan Scott authored
      Summary:
      Now that `MonadIO` is a superclass of `Quasi`, it's a good
      time to bump the `template-haskell` version so that libraries can
      accommodate the change using CPP.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D4007
      3804a7eb
    • Simon Peyton Jones's avatar
      Fix solving of implicit parameter constraints · abed9bf5
      Simon Peyton Jones authored
      Trac #14218 showed that we were not solving implicit-parameter
      constraints correctly.  In particular,
      
      - A tuple constraint could "hide" an implicit-parameter wanted
        constraint, and that in turn could that we solved it from the
        wrong implicit-parameter binding.
      
      - As a special case the HasCallStack constraint (which is just
        short for (IP "callStack" CallStack), was getting mis-solved.
      
      The big change is to arrange that, in TcSMonad.findDict when looking
      for a dictionary, either when looking for a matching inert or solved
      dictionary, we fail for
      
        - Tuples that are hiding implicit parameters
          See Note [Tuples hiding implicit parameters]
      
        - HasCallStack constraints where we have not yet pushed
          on the call-site info
          See Note [Solving CallStack constraints]
      
      I also did a little refactoring
      
      * Move naturallyCoherentClass from Class to TcInteract, its sole
        use site.  Class.hs seems like the wrong place.  (And I also
        do not understand the reason that we need the eq/Coercible/
        Typable stuff in this predicate, but I'll tackle that separately.)
      
      * Move the code that pushes call-site info onto a call stack
        from the "interact" part to the "canonicalise" part of the solver.
      abed9bf5
    • 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