1. 14 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored
      Before, when you attempted to derive an instance for a typeclass,
      e.g.,
      
      ```
      class C1 (a :: Constraint) where
      class C2 where
      
      deriving instance C1 C2
      ```
      
      GHC would complain that `C2`'s data constructors aren't in scope. But
      that
      makes no sense, since typeclasses don't have constructors! By refining
      the
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      
      ```
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      ```
      
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      
      Fixes #11509.
      
      Test Plan: make test TEST=T11509
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2558
      
      GHC Trac Issues: #11509
      d5a4e49d
  2. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
  3. 11 Sep, 2016 1 commit
    • Ryan Scott's avatar
      Fix derived Ix instances for one-constructor GADTs · 7b7ea8f4
      Ryan Scott authored
      Summary:
      Standalone-derived `Ix` instances would panic on GADTs with exactly
      one constructor, since the list of fields was being passed to a function that
      uses `foldl1` in order to generate an implementation for `inRange`. This adds a
      simple check that makes `inRange` be `True` whenever a product type has no
      fields.
      
      Fixes #12583.
      
      Test Plan: make test TEST=12583
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2521
      
      GHC Trac Issues: #12583
      7b7ea8f4
  4. 18 Jul, 2016 1 commit
    • Ryan Scott's avatar
      Make DeriveFunctor work with unboxed tuples · 3fa3fe8a
      Ryan Scott authored
      Summary:
      Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was
      mistaking for actual data constructor arguments. As a result, a derived
      `Functor` instance for a datatype that contained an unboxed tuple would
      generate twice as many arguments as it needed for an unboxed tuple pattern
      match or expression. The solution is to simply put `dropRuntimeRepArgs` in the
      right place.
      
      Fixes #12399.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, osa1
      
      Differential Revision: https://phabricator.haskell.org/D2404
      
      GHC Trac Issues: #12399
      3fa3fe8a
  5. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make unique auxiliary function names in deriving · 895eefa8
      Simon Peyton Jones authored
      In deriving for Data, we make some auxiliary functions, but they
      didn't always get distinct names (Trac #12245).  This patch fixes
      it by using the same mechanism as for dictionary functions, namely
      chooseUniqueOccTc.
      
      Some assocated refactoring came along for the ride.
      895eefa8
  6. 12 May, 2016 1 commit
    • Ryan Scott's avatar
      Fix deriveTyData's kind unification when two kind variables are unified · e53f2180
      Ryan Scott authored
      When `deriveTyData` attempts to unify two kind variables (which can
      happen if both the typeclass and the datatype are poly-kinded), it
      mistakenly adds an extra mapping to its substitution which causes the
      unification to fail when applying the substitution. This can be
      prevented by checking both the domain and the range of the original
      substitution to see which kind variables shouldn't be put into the
      domain of the substitution. A more in-depth explanation is included in
      `Note [Unification of two kind variables in deriving]`.
      
      Fixes #11837.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, goldfire, niteria, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2117
      
      GHC Trac Issues: #11837
      e53f2180
  7. 02 May, 2016 1 commit
    • Ryan Scott's avatar
      Make validDerivPred ignore non-visible arguments to a class type constructor · fa86ac7c
      Ryan Scott authored
      Summary:
      GHC choked when trying to derive the following:
      
      ```
      {-# LANGUAGE GeneralizedNewtypeDeriving #-}
      {-# LANGUAGE PolyKinds #-}
      module Example where
      
      class Category (cat :: k -> k -> *) where
        catId   :: cat a a
        catComp :: cat b c -> cat a b -> cat a c
      
      newtype T (c :: * -> * -> *) a b = MkT (c a b) deriving Category
      ```
      
      Unlike in #8865, where we were deriving `Category` for a concrete type like
      `Either`, in the above example we are attempting to derive an instance of the
      form:
      
      ```
      instance Category * c => Category (T * c) where ...
      ```
      
      (using `-fprint-explicit-kinds` syntax). But `validDerivPred` is checking if
      `sizePred (Category * c)` equals the number of free type variables in
      `Category * c`. But note that `sizePred` counts both type variables //and//
      type constructors, and `*` is a type constructor! So `validDerivPred`
      erroneously rejects the above instance.
      
      The fix is to make `validDerivPred` ignore non-visible arguments to the class
      type constructor (e.g., ignore `*` is `Category * c`) by using
      `filterOutInvisibleTypes`.
      
      Fixes #11833.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, hvr, simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2112
      
      GHC Trac Issues: #11833
      fa86ac7c
  8. 11 Apr, 2016 1 commit
    • Ryan Scott's avatar
      Deriving Functor-like classes should unify kind variables · aadde2b9
      Ryan Scott authored
      While the deriving machinery always unifies the kind of the typeclass
      argument with the kind of the datatype, this proves not to be sufficient
      to produce well kinded instances for some poly-kinded datatypes. For
      example:
      
      ```
      newtype Compose (f :: k2 -> *) (g :: k1 -> k2) (a :: k1)
        = Compose (f (g a)) deriving Functor
      ```
      
      would fail because only `k1` would get unified with `*`, causing the
      following
      ill kinded instance to be generated:
      
      ```
      instance (Functor (f :: k2 -> *), Functor (g :: * -> k2)) =>
        Functor (Compose f g) where ...
      ```
      
      To prevent this, we need to take the subtypes and unify their kinds with
      `* -> *`.
      
      Fixes #10524 for good.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2097
      
      GHC Trac Issues: #10524, #10561
      aadde2b9
  9. 10 Apr, 2016 1 commit
    • Ryan Scott's avatar
      Remove the instantiation check when deriving Generic(1) · 7443e5c8
      Ryan Scott authored
      Previously, deriving `Generic(1)` bailed out when attempting to
      instantiate visible type parameters (#5939), but this instantiation
      check was quite fragile and doesn't interact well with `-XTypeInType`.
      It has been decided that `Generic(1)` shouldn't be subjected to this
      check anyway, so it has been removed, and `gen_Generic_binds`'s
      machinery has been updated to substitute the type variables in a
      generated `Rep`/`Rep1` instance with the user-supplied type arguments.
      
      In addition, this also refactors `Condition` in `TcDeriv` a bit. Namely,
      since we no longer need `tc_args` to check any conditions, the `[Type]`
      component of `Condition` has been removed.
      
      Fixes #11732.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, kosmikus, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2061
      
      GHC Trac Issues: #5939, #11732
      7443e5c8
  10. 15 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11357. · 1eefedf7
      eir@cis.upenn.edu authored
      We were looking at a data instance tycon for visibility info,
      which is the wrong place to look. Look at the data family tycon
      instead.
      
      Also improved the pretty-printing near there to suppress kind
      arguments when appropriate.
      1eefedf7
  11. 17 Feb, 2016 1 commit
    • Ryan Scott's avatar
      Remove superfluous code when deriving Foldable/Traversable · a82956df
      Ryan Scott authored
      Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate
      unnecessary `mempty` and `pure` expressions when it traverses of an
      argument of a constructor whose type does not mention the last type
      parameter. Not only is this inefficient, but it prevents `Traversable`
      from being derivable for datatypes with unlifted arguments (see
      Trac #11174).
      
      The solution to this problem is to adopt a slight change to the
      algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is
      described in [this wiki
      page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu
      nctor#Proposal:alternativestrategyforderivingFoldableandTraversable).
      The wiki page also describes why we don't apply the same changes to the
      algorithm for `-XDeriveFunctor`.
      
      This is techincally a breaking change for users of `-XDeriveFoldable`
      and `-XDeriveTraversable`, since if someone was using a law-breaking
      `Monoid` instance with a derived `Foldable` instance (i.e., one where `x
      <> mempty` does not equal `x`) or a law-breaking `Applicative` instance
      with a derived `Traversable` instance, then the new generated code could
      result in different behavior. I suspect the number of scenarios like
      this is very small, and the onus really should be on those users to fix
      up their `Monoid`/`Applicative` instances.
      
      Fixes #11174.
      
      Test Plan: ./validate
      
      Reviewers: hvr, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1908
      
      GHC Trac Issues: #11174
      a82956df
  12. 20 Jan, 2016 1 commit
    • Ben Gamari's avatar
      Use (&&) instead of `if` in Ix derivation · 5cce0954
      Ben Gamari authored
      We were previously using `if` in the derivation of `Ix` instances. This
      interacts badly with RebindableSyntax as the typechecker doesn't infer
      the type of the argument we give to `tagToEnum#`.
      
      Previously we produced, `if (ch >= ah) then (ch <= bh) else False`.
      
      We now produce `(ch >= ah) && (ch <= bh)`
      
      Fixes #11396.
      
      Test Plan: Validate
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1797
      
      GHC Trac Issues: #11396
      5cce0954
  13. 15 Jan, 2016 1 commit
    • Ryan Scott's avatar
      Expand type/kind synonyms in TyVars before deriving-related typechecking · 165ae440
      Ryan Scott authored
      Before, it was possible to have a datatypes such as
      
      ```
      type ConstantT a b = a
      newtype T (f :: * -> *) (a :: ConstantT * f) = T (f a) deriving Functor
      
      data family TFam (f :: * -> *) (a :: *)
      newtype instance TFam f (ConstantT a f) = TFam (f a) deriving Functor
      ```
      
      fail to eta-reduce because either (1) a TyVar had a kind synonym that
      mentioned another TyVar, or (2) an instantiated type was itself a type
      synonym that mentioned another TyVar. A little bit of tweaking to
      `expandTypeSynonyms` and applying it before the eta-reduction check in
      the `deriving` machinery is sufficient to fix this.
      
      Fixes #11416.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1772
      
      GHC Trac Issues: #11416
      165ae440
  14. 31 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve exprIsBottom · 0579fe99
      Simon Peyton Jones authored
      This fixes Trac #11290, by being sligthtly cleverer about finding
      what expressions are bottom.  Actually this might have minor
      other side benefits.
      0579fe99
  15. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  16. 09 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (Trac #9968) · af77089b
      Simon Peyton Jones authored
      The main issue concerned things like
      
         data T a = MkT a deriving( C Int )
      
      which is supposed to generate
      
         instance C Int (T a) where {}
      
      But the 'Int' argument (called cls_tys in the code) wasn't
      even being passed to inferConstraints and mk_data_eqn, so it
      really had no chance.   DeriveAnyClass came along after this
      code was written!
      
      Anyway I did quite a bit of tidying up in inferConstraints.
      
      Also I discovered that this case was not covered at all
      
         data T a b = MkT a b deriving( Bifunctor )
      
      What constraints should we generate for the instance context?
      We can deal with classes whose last arg has kind *, like Eq, Ord;
      or (* -> *), like Functor, Traversable.  But we really don't have
      a story for classes whose last arg has kind (* -> * -> *).
      
      So I augmented checkSideConditions to check for that and give
      a sensible error message.
      
      ToDo: update the user manual.
      af77089b
  17. 04 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix egregious error in eta-reduction of data families · 1160dc51
      Simon Peyton Jones authored
      This terrible and long-standing bug was shown up by Trac #11148.
      We are trying to eta-reduce a data family instance, so that we
      can then derive Functor or Generic.  But we were assuming, for
      absolutely not reason whatsoever, that the type variables were
      lined up in a convenient order.  The fact that it ever worked
      was a fluke.
      
      This patch fixes it properly.  Main change is in eta_reduce
      in TcInstDcls.tcDataFamInstDecl
      1160dc51
  18. 24 Sep, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix DeriveGeneric for types with same OccName (#10487) · b08a533d
      Ömer Sinan Ağacan authored
      Summary:
      DeriveGeneric generates some data types (for data type constructors and for
      selectors of those constructors) and instances for those types. This patch
      changes name generation for these new types to make it working with data types
      with same names imported from different modules and with data types with same
      names imported from same modules(using module imports).
      
      Bonus content:
      
      - Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some
        redundant partial function applications and to remove a duplicated function.
      - Remove some unused names from `OccName`. (those were used for an old
        implementation of `DeriveGeneric`)
      
      Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin
      
      Reviewed By: bgamari, austin
      
      Subscribers: ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1081
      
      GHC Trac Issues: #10487
      b08a533d
  19. 23 Sep, 2015 1 commit
  20. 22 Sep, 2015 1 commit
  21. 25 Jun, 2015 1 commit
  22. 22 Apr, 2015 1 commit
  23. 07 Mar, 2015 1 commit
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      Summary:
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      
      The current implementation creates `TyCon` representations on the spot.
      
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      
      Reviewers: simonpj, simonmar, austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D652
      
      GHC Trac Issues: #9858
      b359c886
  24. 02 Dec, 2014 2 commits
  25. 18 Oct, 2014 1 commit
    • mgmeier's avatar
      Remove obsolete Data.OldTypeable (#9639) · 7369d259
      mgmeier authored
      This finally removes the `Data.OldTypeable` module (which
      has been deprecated in 7.8), from `base`, compiler and testsuite.
      
      The deprecated `Typeable{1..7}` aliases in `Data.Typeable` are not
      removed yet in order to give existing code a bit more time to adapt.
      
      Reviewed By: hvr, dreixel
      
      Differential Revision: https://phabricator.haskell.org/D311
      7369d259
  26. 24 Jul, 2014 1 commit
  27. 06 Jun, 2014 1 commit
  28. 26 May, 2014 1 commit
  29. 08 Apr, 2014 1 commit
  30. 05 Apr, 2014 1 commit
  31. 23 Mar, 2014 1 commit
  32. 14 Mar, 2014 1 commit
  33. 10 Mar, 2014 1 commit
  34. 07 Mar, 2014 2 commits
  35. 09 Feb, 2014 2 commits
  36. 02 Oct, 2013 1 commit
  37. 18 Sep, 2013 1 commit