1. 02 Oct, 2016 1 commit
  2. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  3. 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
  4. 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
  5. 05 Sep, 2016 2 commits
  6. 18 Jul, 2016 2 commits
  7. 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
  8. 22 Jun, 2016 1 commit
  9. 20 Jun, 2016 3 commits
  10. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b
  11. 24 May, 2016 1 commit
  12. 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
  13. 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
  14. 28 Apr, 2016 1 commit
  15. 26 Apr, 2016 1 commit
  16. 20 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      SCC analysis for instances as well as types/classes · 353d8ae6
      Simon Peyton Jones authored
      This big patch is in pursuit of Trac #11348.
      
      It is largely the work of Alex Veith (thank you!), with some
      follow-up simplification and refactoring from Simon PJ.
      
      The main payload is described in RnSource
        Note [Dependency analysis of type, class, and instance decls]
      which is pretty detailed.
      
      * There is a new data type HsDecls.TyClGroup, for a strongly
        connected component of type/class/instance/role decls.
      
        The hs_instds field of HsGroup disappears, in consequence
      
        This forces some knock-on changes, including a minor
        haddock submodule update
      
      Smaller, weakly-related things
      
      * I found that both the renamer and typechecker were building an
        identical env for RoleAnnots, so I put common code for
        RoleAnnotEnv in RnEnv.
      
      * I found that tcInstDecls1 had very clumsy error handling, so I
        put it together into TcInstDcls.doClsInstErrorChecks
      353d8ae6
  17. 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
  18. 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
  19. 24 Mar, 2016 1 commit
    • Ben Gamari's avatar
      Show: Restore redundant parentheses around records · 1448f8ab
      Ben Gamari authored
      As discussed in #2530 we are going to continue to produce parentheses
      here in order to preserve compatibility with previous GHC releases. It
      was found that dropped parentheses would break some testsuites which
      compared against output from Show. This has been documented in the users
      guide.
      
      This reverts commit 5692643c.
      
      Test Plan: Validate
      
      Reviewers: hvr, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2027
      
      GHC Trac Issues: #2350
      1448f8ab
  20. 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
  21. 25 Feb, 2016 2 commits
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
    • thomie's avatar
      Testsuite: delete empty files [skip ci] · 9b49c65f
      thomie authored
      9b49c65f
  22. 23 Feb, 2016 3 commits
  23. 20 Feb, 2016 1 commit
    • nushio's avatar
      Add test (only) to assure that #11535 is fixed · 1ef7add0
      nushio authored
      Ticket #11535 dealt with derived Read instances of infix Unicode
      value constructors. GHC 7.10.3 used to derive (Read/Show)
      instances so that `read . show` for values of such types had no
      parse.
      
      The issue has been fixed by other compiler update. This patch
      adds only tests, so that derived instance of Read/Show for infix
      Unicode value constructors has correct parse, satisfying Haskell
      2010 Specification.
      
      Resolves: #11535
      
      Test Plan: `make test TEST=T11535`
      
      Reviewers: austin, rwbarton, thomie, bgamari
      
      Reviewed By: rwbarton, thomie, bgamari
      
      Subscribers: rwbarton, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1884
      
      GHC Trac Issues: #11535
      1ef7add0
  24. 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
  25. 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
  26. 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
  27. 07 Jan, 2016 2 commits
    • Simon Peyton Jones's avatar
      Use an Implication in 'deriving' error · 02c1c573
      Simon Peyton Jones authored
      Trac #11437 showed that erroneous constraints from a 'deriving'
      clause need to be wrapped in an Implication to properly scope
      their skolems.
      
      The main change is in TcDeriv.simplifyDeriv; the call to
      buildImplicationFor is new.
      02c1c573
    • Simon Peyton Jones's avatar
      Tidy up tidySkolemInfo · 290a553e
      Simon Peyton Jones authored
      Previously tidySkolemInfo used tidyOpenType, and returned a new
      TidyEnv.  But that's not needed any more, because all the skolems
      should be in scope in the constraint tree.
      
      I also removed a (now-unnecessary) field of UnifyForAllSkol
      290a553e
  28. 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
  29. 17 Dec, 2015 2 commits
  30. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
  31. 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