GitLab

I'm astonished that anything worked without this!

Fixes Trac #14339

Summary:
For some asinine reason, we were suppressing warnings when
deriving associated type family instances with `DeriveAnyClass`. That seems
like a bad idea. Let's not do that.

Along the way, I noticed that the error contexts associated with these
newly emitted warnings were less than ideal, so I did some minor refactoring
to improve the story there.

Fixes #14094

Test Plan: ./validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14094

Differential Revision: https://phabricator.haskell.org/D3828

Simon Peyton Jones authored Aug 02, 2017 and Ryan Scott committed Aug 02, 2017

This was a simple slip, that gave rise to the bug reported in
comment:13 of Trac #14045.  We were supplying roles to mkAlgTyCon
that didn't match the tyvars.

Trac #13998 showed that default methods were getting bogus tyvar
binder visiblity info; and that it matters in the code genreated
by the default-method fill-in mechanism

* The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders
  with the right visibility info by getting TyConBinders from the
  class TyCon.  (Previously we made up visiblity info, but that
  caused #13998.)

* Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder]
  which can build correct forall binders for
    a) default methods (Trac #13998)
    b) data constructors
  This was originally BuildTyCl.mkDataConUnivTyVarBinders

* Move mkTyVarBinder, mkTyVarBinders from Type to Var

Ryan Scott authored Jul 11, 2017 and Ben Gamari committed Jul 11, 2017

Although derived `Read`, `Show`, and `Generic` instances technically
don't //use// the record selectors of the data type for which an
instance is being derived, the derived code is affected by the
//presence// of record selectors. As a result, we should suppress
`-Wunused-binds` for those record selectors when deriving these classes.
This is accomplished by threading through more information from
`hasStockDeriving`.

Test Plan: make test TEST=T13919

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13919

Differential Revision: https://phabricator.haskell.org/D3704

Summary:
This amounts to using `exactTyCoVarsOfType` instead of
`tyCoVarsOfType` in the right place. I also fixed a similar issue for
`-XDatatypeContexts` while I was in town (but couldn't be bothered to add a
test for it).

Test Plan: make test TEST=T13813

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13813

Differential Revision: https://phabricator.haskell.org/D3635

David Feuer authored Apr 01, 2017 and David Feuer committed Apr 01, 2017

There's no obvious reason to derive the definition of `showList`,
manually inlining the default definition. Let's just use
the default definition in the usual manner.

Garbage collect a few unused `RdrNames` from `PrelNames`:
`showList`, `showList__`, and `/=`.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3403

David Feuer authored Mar 30, 2017 and David Feuer committed Mar 30, 2017

Make `Functor`, `Foldable`, and `Traversable` take advantage
of the case where the type parameter is phantom. In this case,

* `fmap _ = coerce`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (coerce x)`

For the sake of consistency and especially simplicity, make other types
with no data constructors behave the same:

* `fmap _ x = case x of`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (case x of)`

Similarly, for `Generic`,

* `to x = case x of`
* `from x = case x of`

Give all derived methods for types without constructors appropriate
arities. For example,

```
    compare _ _ = error ...
```

rather than

```
    compare = error ...
```

Fixes #13117 and #13328

Reviewers: austin, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: ekmett, RyanGlScott, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3374

This bug was causing Trac #13297.

We were recomputing ds_tvs, and doing it wrongly (by omitting
variables that appear only in mtheta).  But actually plain 'tvs'
is just fine.  So code deleted, and bug fixed.

This patch fixes Trac #13272.  The general approach was fine, but
we were simply not generating the correct implication constraint
(in particular generating fresh unification variables).  I added
a lot more commentary to Note [Gathering and simplifying
constraints for DeriveAnyClass]

I'm still not very happy with the overall architecture.  It feels
more complicate than it should.

Summary:
Currently, `DeriveAnyClass` has two glaring flaws:

* It only works on classes whose argument is of kind `*` or `* -> *` (#9821).
* The way it infers constraints makes no sense. It basically co-opts the
  algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or
  `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly
  constrained instances, which in extreme cases can lead to legitimate things
  failing to typecheck (#12594). Or even worse, it can trigger GHC panics
  (#12144 and #12423).

This completely reworks the way `DeriveAnyClass` infers constraints to fix
these two issues. It now uses the type signatures of the derived class's
methods to infer constraints (and to simplify them). A high-level description
of how this works is included in the GHC users' guide, and more technical notes
on what is going on can be found as comments (and a Note) in `TcDerivInfer`.

Fixes #9821, #12144, #12423, #12594.

Test Plan: ./validate

Reviewers: dfeuer, goldfire, simonpj, austin, bgamari

Subscribers: dfeuer, thomie

Differential Revision: https://phabricator.haskell.org/D2961

Thomas Miedema authored Jan 22, 2017 and Ben Gamari committed Jan 22, 2017

The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.

Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.

    find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;

Tests containing inline comments or multiline strings are not modified.

Preparation for #12223.

Test Plan: Harbormaster

Reviewers: austin, hvr, simonmar, mpickering, bgamari

Reviewed By: mpickering

Subscribers: mpickering

Differential Revision: https://phabricator.haskell.org/D3000

GHC Trac Issues: #12223

Ryan Scott authored Nov 10, 2016 and Ben Gamari committed Nov 10, 2016

When `GeneralizedNewtypeDeriving` is used with a type class that has no
methods, it will generate a redundant context, and as a result, it can
trigger warnings when compiled with `-Wredundant-constraints`. This is a
simple change in behavior to check beforehand if a class has methods
when deriving it with GND, and if it has no methods, avoid inferring the
redundant context.

Beware that the test for #6088, which used to be expected to fail, now
compiles without issue since it doesn't infer a problematic instance
context.

Thanks to Simon Peyton Jones for doing the necessary refactoring in
f05d685a.

Fixes #12814.

Test Plan: ./validate

Reviewers: goldfire, rwbarton, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2692

GHC Trac Issues: #12814

Summary:
This implements the ability to derive associated type family instances
for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the
users' guide additions for how this works; I essentially follow the pattern
laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18.

Fixes #2721 and #8165.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: simonpj

Subscribers: mpickering, thomie

Differential Revision: https://phabricator.haskell.org/D2636

GHC Trac Issues: #2721, #8165

Summary:
To fix this issue, we simply disable `RebindableSyntax` whenever we rename
the code generated from a deriving clause.

Fixes #12688.

Test Plan: make test TEST=T12688

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2591

GHC Trac Issues: #12688

Ryan Scott authored Oct 14, 2016 and Ben Gamari committed Oct 14, 2016

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

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.

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

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

[ci skip]

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.

Ryan Scott authored May 11, 2016 and Ben Gamari committed May 12, 2016

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

Ryan Scott authored May 02, 2016 and Ryan Scott committed May 02, 2016

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

Ryan Scott authored Apr 11, 2016 and Ben Gamari committed Apr 11, 2016

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

Ryan Scott authored Apr 10, 2016 and Ben Gamari committed Apr 10, 2016

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

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.

barrucadu authored Feb 25, 2016 and Herbert Valerio Riedel committed Feb 25, 2016

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

Ryan Scott authored Feb 17, 2016 and Ben Gamari committed Feb 17, 2016

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

Ben Gamari authored Jan 19, 2016 and Ben Gamari committed Jan 20, 2016

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

Ryan Scott authored Jan 15, 2016 and Ben Gamari committed Jan 15, 2016

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

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.

This fixes Trac #11290, by being sligthtly cleverer about finding
what expressions are bottom.  Actually this might have minor
other side benefits.

And fix a redundant constraint warning in a test that requires
primitive.

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.