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.

This unfortunately had quite a number of knock-on effects, including a need for
new releases of directory and unix.

These are right on the edge of acceptance and are only reproducible on a
stressed machine.

We are now tracking the 2.0 branch.

I forgot to fold these in to the patch merged earlier.

If a JoinId (bogusly) ends up in an argument position we printed
    f jump j
rather than
    f (jump j)

Easy to fix.

The desugarer was producing an empty Rec group, which is never
supposed to happen.  This small patch stops that happening.

Next up: Lint should check.

I spent about two hours today hunting fruitlessly for a simplifier
bug (when fixing Trac #13255), only to find that it was caused by
-ddump-X silently suppressing all ticks in Core.

I think this has happened to me once before.

So I've changed to make tick-printing on by default (like coercions,
etc), with a flag -dsuppress-ticks (like -dsuppress-coercions) to
suppress them.

Blargh.

-dppr-ticks is still there, but deprecated.

They take a long time to run, and are effectively superseded by the -ddump-*-ast
tests.

Test Plan: none

Reviewers: simonmar, bgamari, austin

Subscribers: thomie

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

These things are simply too expensive to generate at the moment. More
work is needed here; see #13276 and #13261.

This at long last realizes the ideas for type-indexed Typeable discussed in A
Reflection on Types (#11011). The general sketch of the project is described on
the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
index to `TypeRep`,

    data TypeRep (a :: k)

This index allows the typechecker to reason about the type represented by the `TypeRep`.
This index representation mechanism is exposed as `Type.Reflection`, which also provides
a number of patterns for inspecting `TypeRep`s,

```lang=haskell
pattern TRFun :: forall k (fun :: k). ()
              => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                        (arg :: TYPE r1) (res :: TYPE r2).
                 (k ~ Type, fun ~~ (arg -> res))
              => TypeRep arg
              -> TypeRep res
              -> TypeRep fun

pattern TRApp :: forall k2 (t :: k2). ()
              => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
              => TypeRep a -> TypeRep b -> TypeRep t

-- | Pattern match on a type constructor.
pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a

-- | Pattern match on a type constructor including its instantiated kind
-- variables.
pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
```

In addition, we give the user access to the kind of a `TypeRep` (#10343),

    typeRepKind :: TypeRep (a :: k) -> TypeRep k

Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
newly levity polymorphic (->) type constructor.

Library changes
---------------

The primary change here is the introduction of a Type.Reflection module to base.
This module provides access to the new type-indexed TypeRep introduced in this
patch. We also continue to provide the unindexed Data.Typeable interface, which
is simply a type synonym for the existentially quantified SomeTypeRep,

    data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep

Naturally, this change also touched Data.Dynamic, which can now export the
Dynamic data constructor. Moreover, I removed a blanket reexport of
Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
now).

We also add a kind heterogeneous type equality type, (:~~:), to
Data.Type.Equality.

Implementation
--------------

The implementation strategy is described in Note [Grand plan for Typeable] in
TcTypeable. None of it was difficult, but it did exercise a number of parts of
the new levity polymorphism story which had not yet been exercised, which took
some sorting out.

The rough idea is that we augment the TyCon produced for each type constructor
with information about the constructor's kind (which we call a KindRep). This
allows us to reconstruct the monomorphic result kind of an particular
instantiation of a type constructor given its kind arguments.

Unfortunately all of this takes a fair amount of work to generate and send
through the compilation pipeline. In particular, the KindReps can unfortunately
get quite large. Moreover, the simplifier will float out various pieces of them,
resulting in numerous top-level bindings. Consequently we mark the KindRep
bindings as noinline, ensuring that the float-outs don't make it into the
interface file. This is important since there is generally little benefit to
inlining KindReps and they would otherwise strongly affect compiler performance.

Performance
-----------

Initially I was hoping to also clear up the remaining holes in Typeable's
coverage by adding support for both unboxed tuples (#12409) and unboxed sums
(#13276). While the former was fairly straightforward, the latter ended up being
quite difficult: while the implementation can support them easily, enabling this
support causes thousands of Typeable bindings to be emitted to the GHC.Types as
each arity-N sum tycon brings with it N promoted datacons, each of which has a
KindRep whose size which itself scales with N. Doing this was simply too
expensive to be practical; consequently I've disabled support for the time
being.

Even after disabling sums this change regresses compiler performance far more
than I would like. In particular there are several testcases in the testsuite
which consist mostly of types which regress by over 30% in compiler allocations.
These include (considering the "bytes allocated" metric),

 * T1969:  +10%
 * T10858: +23%
 * T3294:  +19%
 * T5631:  +41%
 * T6048:  +23%
 * T9675:  +20%
 * T9872a: +5.2%
 * T9872d: +12%
 * T9233:  +10%
 * T10370: +34%
 * T12425: +30%
 * T12234: +16%
 * 13035:  +17%
 * T4029:  +6.1%

I've spent quite some time chasing down the source of this regression and while
I was able to make som improvements, I think this approach of generating
Typeable bindings at time of type definition is doomed to give us unnecessarily
large compile-time overhead.

In the future I think we should consider moving some of all of the Typeable
binding generation logic back to the solver (where it was prior to
91c6b1f5). I've opened #13261 documenting this
proposal.

This is generalizes the kind of `(->)`, as discussed in #11714.

This involves a few things,

 * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
binders,
  ```lang=haskell
(->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
               (a :: TYPE r1) (b :: TYPE r2).
        a -> b -> *
  ```

 * Unsaturated applications of `(->)` are expressed as explicit
`TyConApp`s

 * Saturated applications of `(->)` are expressed as `FunTy` as they are
currently

 * Saturated applications of `(->)` are expressed by a new `FunCo`
constructor in coercions

 * `splitTyConApp` needs to ensure that `FunTy`s are split to a
`TyConApp`
   of `(->)` with the appropriate `RuntimeRep` arguments

 * Teach CoreLint to check that all saturated applications of `(->)` are
represented with `FunTy`

At the moment I assume that `Constraint ~ *`, which is an annoying
source of complexity. This will
be simplified once D3023 is resolved.

Also, this introduces two known regressions,

`tcfail181`, `T10403`
=====================
Only shows the instance,

    instance Monad ((->) r) -- Defined in ‘GHC.Base’

in its error message when -fprint-potential-instances is used. This is
because its instance head now mentions 'LiftedRep which is not in scope.
I'm not entirely sure of the right way to fix this so I'm just accepting
the new output for now.

T5963 (Typeable)
================

T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
fingerprint without the RuntimeRep variables that (->) expects. This
will be fixed with the merge of D2010.

Haddock performance
===================

The `haddock.base` and `haddock.Cabal` tests regress in allocations by
about 20%. This certainly hurts, but it's also not entirely unexpected:
the size of every function type grows with this patch and Haddock has a
lot of functions in its heap.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
A number of changes:

- Keep the TcGblEnv from typechecking the local signature
  around when we do merging.  In particular, we setup
  tcg_imports and tcg_rdr_env according to the local
  signature.  This improves our error output (for example,
  see bkpfail04) and also fixes a bug with reexporting
  modules in signatures (see bkpreex07)

- Fix a bug in thinning, where if we had signature A(module A),
  this previously would have *thinned out* all of the inherited
  signatures.  Now we treat every inherited signature as having
  come from an import like "import A", so a module A reexport
  will pick them up.

- Recompilation checking now keeps track of dependent source files
  of the source signature; previously we forgot to retain this
  info.

There's a manual update too.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: thomie

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

Summary:
Previously we weren't tracking these dependencies at all,
because we couldn't "find" the interface for {A.H}.  Now
we've associated hole names to the correct module identity
so we will pick them up.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: thomie, snowleopard

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

Summary:
Recompilation avoidance checks if -this-unit-id has changed by relying
on the "wanted module" check in readIface ("Something is amiss...").
Unfortunately, this check didn't check if the instantiation made
sense, which meant that if you changed the signatures of a Backpack
package, we'd still treat the old signatures as up-to-date.

The way I fixed this was by having findAndReadIface take in a 'Module'
representing the /actual/ module we were intending to lookup.  We
convert this into the 'Module' we expect to see in 'mi_module' and
now do a more elaborate check that will also verify that instantiations
make sense.

Along the way, I robustified the logging infrastructure for
recompilation checking, and folded wrongIfaceModErr (which
was dead code) into the error message.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: thomie, snowleopard

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

This replaces three methods in OutputableBndr with one,
and adds comments.

There's also a tiny change in the placement of equals signs in
debug-prints.  I like it better that way, but if it complicates
life for anyone we can put it back.

There was a missing substTy in cseCase!  Wow.  I'm surprised
it has not caused problems.  Anyway, easily fixed.

I found that tests
  parser/should_compile/DumpRenamedAst
and friends were printing uniques, which makes the test fragile.
But -dsuppress-uniques made no difference!  It turned out that
pprName wasn't properly consulting Opt_SuppressUniques.

This patch fixes the problem, and updates those three tests to
use -dsuppress-uniques

I think this is due to
  commit 6bab649b
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Thu Feb 16 09:42:32 2017 +0000

      Improve checking of joins in Core Lint

Improvement is around 5%.

This fixes Trac #13285.

The CallStack stuff is all driven by a CtOrigin of (OccurenceOf f),
and we were instead using SectionOrigin.  Boo!

Easily fixed; and I did a little refactoring as usual.

This patch addresses the rather expensive treatment of join points,
identified in Trac #13220 comment:17

Before we were tracking the "bad joins".  Now we track the good ones.
That is easier to think about, and much more efficient; see CoreLint
Note [Join points].

On the way I did some other modest refactoring, among other things
removing a duplicated call of lintIdBndr for let-bindings.

On teh

Test Plan: validate

Reviewers: bgamari, austin, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

rwbarton authored 8 years ago and Ben Gamari committed 8 years ago

Preparation for #13102, which needs to add more logic to
runTcInteractive, which would need to be duplicated in deSugarExpr.

In order to break an import cycle, I had to move
"Dependency/fingerprinting code" to a new module
DsUsage; which seems sensible anyways.

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, snowleopard

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

rwbarton authored 8 years ago and Ben Gamari committed 8 years ago

We previously checked type family instance declarations
in a module for consistency with all instances that we happened
to have read into the EPS or HPT. It was possible to arrange that
an imported type family instance (used by an imported function)
was in a module whose interface file was never read during
compilation; then we wouldn't check consistency of local instances
with this imported instance and as a result type safety was lost.

With this patch, we still check consistency of local type family
instances with all type family instances that we have loaded; but
we make sure to load the interface files of all our imports that
define family instances first. More selective consistency checking
is left to #13102.

On the other hand, we can now safely assume when we import a module
that it has been checked for consistency with its imports. So we
can save checking in checkFamInstConsistency, and overall we should
have less work to do now.

This patch also adds a note describing the Plan for ensuring type
family consistency.

Test Plan: Two new tests added; harbormaster

Reviewers: austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: ggreif, thomie

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

Adam Gundry authored 8 years ago and Ben Gamari committed 8 years ago

This implements automatic constraint solving for the new HasField class
and modifies the existing OverloadedLabels extension, as described in
the GHC proposal
(https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current
form of the proposal, it does *not* currently introduce a separate
`OverloadedRecordFields` extension.

This replaces D1687.

The users guide documentation still needs to be written, but I'll do
that after the implementation is merged, in case there are further
design changes.

Test Plan: new and modified tests in overloadedrecflds

Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering

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

Expressions like the following will now typecheck:

```
    data A x = A deriving Show

    class ToA a x where
       toA :: a -> A x

    instance ToA Integer x where
       toA _ = A

    main = print (toA 5 :: A Bool)
```

The new defaulting rules are

Find all the unsolved constraints. Then:

* Find those that have exactly one free type variable, and partition
  that subset into groups that share a common type variable `a`.
* Now default `a` (to one of the types in the default list) if at least
  one of the classes `Ci` is an interactive class

Reviewers: goldfire, bgamari, austin, mpickering, simonpj

Reviewed By: bgamari, simonpj

Subscribers: mpickering, simonpj, goldfire, thomie

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

Tamar Christina authored 8 years ago and Ben Gamari committed 8 years ago

This corrects the `jump islands` calculations for Windows.  The code was
incorrectly creating a new entry for every `usage` of a symbol instead
of every used symbol. e.g. if a symbol is used 5 times it used to create
5 jump islands. This is incorrect and not in line with what the `ELF`
and `Mach-O` linkers do. Also since we allocate `n` spaces where `n` is
number of symbols, we would quickly run out of space and abort.

Test Plan: ./validate

Reviewers: simonmar, hvr, erikd, bgamari, austin

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

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