1. 19 Oct, 2017 3 commits
    • Ryan Scott's avatar
      Error when deriving instances in hs-boot files · 101a8c77
      Ryan Scott authored
      Summary:
      According to the GHC users' guide, one cannot derive
      instances for data types in `.hs-boot` files.
      However, GHC was not enforcing this in practice, which led to
      #14365.
      
      Fix this by actually throwing an error if a derived instance is
      detected in an `.hs-boot` file (and recommend how to fix it in the
      error message.)
      
      Test Plan: make test TEST=T14365
      
      Reviewers: ezyang, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #14365
      
      Differential Revision: https://phabricator.haskell.org/D4102
      101a8c77
    • Ryan Scott's avatar
      Disable -XRebindableSyntax when running internal GHCi expressions · e023e78b
      Ryan Scott authored
      Summary:
      It's well known that `-XRebindableSyntax` doesn't play
      nicely with some of the internal expressions that GHCi runs. #13385
      was one example where this problem arose, which was fixed at the time
      by simply avoiding the use of `do`-notation in these internal GHCi
      expressions. That seemed to work, but it was a technique that proved
      not to scale, as #14342 demonstrated //another// example where
      `-XRebindableSyntax` can bite.
      
      Instead of delicately arranging the internal GHCi expressions to
      avoid anything that might be covered under `-XRebindableSyntax`,
      this patch takes the much more direct approach of disabling
      `-XRebindableSyntax` entirely when running any internal GHCi
      expression. This shouldn't hurt, since nothing internal to GHCi was
      taking advantage of the extension in the first place, and moreover,
      we can have greater confidence that some other obscure
      `-XRebindableSyntax` corner case won't pop up in the future. As an
      added bonus, this lets us once again use `do`-notation in the code
      that had to be changed when #13385 was (hackily) fixed before.
      
      Test Plan: make test TEST=T14342
      
      Reviewers: bgamari, austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14342
      
      Differential Revision: https://phabricator.haskell.org/D4086
      e023e78b
    • Ryan Scott's avatar
      Accept test output for #14350 · 20ae22b0
      Ryan Scott authored
      20ae22b0
  2. 18 Oct, 2017 2 commits
    • Simon Peyton Jones's avatar
      Better solving for representational equalities · 5a66d574
      Simon Peyton Jones authored
      This patch adds a bit of extra solving power for representational
      equality constraints to fix Trac #14333
      
      The main changes:
      
      * Fix a buglet in TcType.isInsolubleOccursCheck which wrongly
        reported a definite occurs-check error for (a ~R# b a)
      
      * Get rid of TcSMonad.emitInsolubles.  It had an ad-hoc duplicate-removal
        piece that is better handled in interactIrred, now that insolubles
        are Irreds.
      
        We need a little care to keep inert_count (which does not include
        insolubles) accurate.
      
      * Refactor TcInteract.solveOneFromTheOther, to return a much simpler
        type.  It was just over-complicated before.
      
      * Make TcInteract.interactIrred look for constraints that match
        either way around, in TcInteract.findMatchingIrreds
      
      This wasn't hard and it cleaned up quite a bit of code.
      5a66d574
    • Simon Peyton Jones's avatar
      Don't deeply expand insolubles · 74cd1be0
      Simon Peyton Jones authored
      Trac #13450 went bananas if we expand insoluble constraints.
      Better just to leave them un-expanded.
      
      I'm not sure in detail about why it goes so badly wrong; but
      regardless, the less we mess around with insoluble contraints
      the better the error messages will be.
      74cd1be0
  3. 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
  4. 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
  5. 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
  6. 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
  7. 06 Oct, 2017 1 commit
  8. 05 Oct, 2017 2 commits
  9. 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
  10. 02 Oct, 2017 1 commit
  11. 29 Sep, 2017 1 commit
  12. 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
  13. 27 Sep, 2017 1 commit
  14. 26 Sep, 2017 3 commits