GitLab

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

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

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

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

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

When the `GCC` driver envokes the pipeline a `SPEC` is used to determine
how to configure the compiler and which libraries to pass along.

For Windows/mingw, this specfile is
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h

This expands the list of base DLLs with the ones that GCC always links,
and adds extra sibling dlls of `stdc++` in case it is linked in.

Following D3028 this patch only needs to load the always load only the
top level individual shared libs.

Test Plan: ./validate

Reviewers: RyanGlScott, austin, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: RyanGlScott, thomie, #ghc_windows_task_force

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

A variety of panics were possible because the get_op function in
RnTypes didn't handle the possibility that its argument might be an
ambiguous record field. I've made its return type more informative to
correctly handle occurrences of record fields.  Fixes Trac #13132.

Test Plan: new test
overloadedrecflds/should_fail/T13132_duplicaterecflds

Reviewers: bgamari, simonpj, austin

Reviewed By: bgamari

Subscribers: thomie

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

Test Plan: Validate

Reviewers: simonpj, austin

Subscribers: thomie

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

- Fixes (#12636).
- changes all the typecasts to _unsinged long long_ to
  have the format specifiers work.

Reviewers: austin, bgamari, erikd, simonmar, Phyx

Reviewed By: erikd, Phyx

Subscribers: thomie

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

While this apparently didn't matter on Linux, the OS X toolchain seems
to treat local and external symbols differently during linking. Namely,
the linker assumes that an external symbol marks the beginning of a new,
unused procedure, and consequently drops it.

Fixes regression introduced in D2741.

Test Plan: `debug` testcase on OS X

Reviewers: austin, simonmar, rwbarton

Reviewed By: rwbarton

Subscribers: rwbarton, thomie

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

While the intent is good, they are actually too aggressive:
if a module reexports an identifier from a signature, we will
warn (even though we should not!)  We'll have to implement
this differently.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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

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

Test Plan: validate

Reviewers: bgamari, simonpj, austin

Subscribers: thomie

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

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

Using `WORDS_BIGENDIAN` wasn't such a great idea after all!
When cross compiling host and target endianess may differ and
`WORDS_BIGENDIAN` refers to host endianess.

Reviewers: austin, bgamari, trofi

Reviewed By: bgamari, trofi

Subscribers: rwbarton, trofi, thomie

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

Previously this was added only to the RTS's C files (those are the bulk
of it though), but there are C bits in ghc-prim, integer-gmp and base
too.

Followup for #8405, allows the large table of character properties in
base to be stripped when not used.

Test Plan: validate

Reviewers: austin, bgamari, simonmar

Reviewed By: bgamari

Subscribers: thomie, snowleopard

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

The bug is that the check `if (size - w > count)` should be
`if (size - w >= count)` instead (`>=` instead of `>`),
because we can do the write all fine if it fits exactly.
This allows us to do 1 instead of 2 write syscalls the case it fits.

An example of when this matters is when an application writes output
in chunks that are a fraction of the handle buffer size.

For example, assume the buffer size is 8 KB, and the application writes
four 2 KB chunks.
Until now, this would result in 3 copies to the handle buffer, but
the 4th one would not be allowed in by `size - w > count`
(because `size - w == count` is the case), so we'd end up with a write
syscall of only 6 KB data instead of 8 KB, thus creating more syscalls
overall.

Implementing this fix (switching to `size - w >= count`), we also have
to flush the buffer if we fill it completely.

If we made only the changes described so far, that would have the
unintended side effect that writes of the size equal to the handle
buffer size (`count == size`) suddenly also go to the handle buffer
first: The data would first be copied to the handle buffer, and then
immediately get flushed to the underlying FD.  We don't want that extra
`memcpy`, because it'd be unnecessary: The point of handle buffering is
to coalesce smaller writes, and there are no smaller writes in this
case.  For example, if you specify 8 KB buffers (which menas you want
your data to be written out in 8 KB blocks), and you get data that's
already 8 KB in size, you can write that out as an 8 KB straight away,
zero-copy fashion.  For this reason, adding to the handle buffer now got
an additional condition `count < size`.  That way, writes equal to the
buffer size go straight to the FD, as they did before this commit.

Reviewers: simonmar, austin, hvr, bgamari

Reviewed By: simonmar

Subscribers: mpickering, thomie

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

Until now, any `hPutBuf` that wrote `>= the handle buffer size` would
trigger an unnecessary `write("")` system call before the actual write
system call.

This is fixed by making sure that we never flush an empty handle buffer:
Only flush `when (w > 0)`.

Reviewers: simonmar, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie

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