GitLab

Summary:
Previously, if `reifyInstances` failed to discover a `Name` during
renaming, it would blindy charge into typechecking, at which point GHC would
become very confused at the absence of that `Name` and throw an internal error.
A simple workaround is to fail eagerly after renaming errors.

Test Plan: make test TEST=T13837

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13837

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

Trac #14000 showed up two errors

* In TcRnTypes.dropInsolubles we dropped all implications, which
  might contain the very insolubles we wanted to keep.  This was
  an outright error, and is why the out-of-scope error was actually
  lost altogether in Trac #14000

* In TcSimplify.simplifyInfer, if there are definite (insoluble)
  errors, it's better to suppress the following ambiguity test,
  because the type may be bogus anyway.  See TcSimplify
  Note [Quantification with errors].  This fix seems a bit clunky,
  but it'll do for now.

The uo_thing field of TypeEqOrigin is used to track the
"thing" (either term or type) that has the type (kind) stored
in the TypeEqOrigin fields. Previously, this was sometimes a
proper Core Type, which needed zonking and tidying. Now, it
is only HsSyn: much simpler, and the error messages now use
the user-written syntax.

But this aspect of uo_thing didn't cause #13819; it was the
sibling field uo_arity that did. uo_arity stored the number
of arguments of uo_thing, useful when reporting something
like "should have written 2 fewer arguments". We wouldn't want
to say that if the thing didn't have two arguments. However,
in practice, GHC was getting this wrong, and this message
didn't seem all that helpful. Furthermore, the calculation
of the number of arguments is what caused #13819 to fall over.
This patch just removes uo_arity. In my opinion, the change
to error messages is a nudge in the right direction.

Test case: typecheck/should_fail/T13819

Summary:
We were unconditionally reporting `Illegal binding of built-in syntax`
in an error message, but this error doesn't make sense in certain Template
Haskell scenarios which can trigger it. Let's give a more sensible error
message by first checking if the name we're binding really is built-in syntax,
using the handy `isBuiltInOcc_maybe` function.

Test Plan: make test TEST=T13968

Reviewers: bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: goldfire, rwbarton, thomie

GHC Trac Issues: #13968

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

Previously datatype names were not paraenthesized (#13887).

Reviewers: austin, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie

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

transitive_deps_set was incorrect, it was not considering the
dependencies of dependencies in some cases. I've corrected it and tidied
it up a little.

The test case from leftaroundabout, as linked to from the ticket, is
added with small modifications to flatten directory structure.

Test Plan: make test TEST=T13949

Reviewers: austin, bgamari, alexbiehl

Reviewed By: alexbiehl

Subscribers: rwbarton, thomie, alexbiehl

GHC Trac Issues: #13949

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

Reviewers: RyanGlScott, austin, goldfire, bgamari

Reviewed By: RyanGlScott, goldfire, bgamari

Subscribers: rwbarton, thomie

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

Using Template Haskell, one can construct lambda expressions with no
arguments. The pretty-printer isn't aware of this fact, however. This
changes that.

Test Plan: make test TEST=T13856

Reviewers: bgamari, austin, goldfire

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13856

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

Reviewers: austin, bgamari, goldfire

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13782

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

`repNonArrowKind` was missing a case for `HsKindSig`, which this
commit adds. Fixes #13781.

Test Plan: make test TEST=T13781

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, thomie

GHC Trac Issues: #13781

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

This patch relates to Trac #8025

The goal here is to enable typechecking of packages that contain some
template haskell. Prior to this patch, compilation of a package with
-fno-code would fail if any functions in the package were called from
within a splice.

downsweep is changed to do an additional pass over the modules,
targetting any ModSummaries transitively depended on by a module that
has LangExt.TemplateHaskell enabled. Those targeted modules have
hscTarget changed from HscNothing to the default target of the platform.

There is a small change to the prevailing_target logic to enable this.

A simple test is added.

I have benchmarked with and without a patched haddock
(available:https://github.com/duog/haddock/tree/wip-no-explicit-th-compi
lation).  Running cabal haddock on the wreq package results in a 25%
speedup on my machine:

time output from patched cabal haddock:

real    0m5.780s
user    0m5.304s
sys     0m0.496s
time output from unpatched cabal haddock:

real    0m7.712s
user    0m6.888s
sys     0m0.736s

Reviewers: austin, bgamari, ezyang

Reviewed By: bgamari

Subscribers: bgamari, DanielG, rwbarton, thomie

GHC Trac Issues: #8025

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

`collect_lpat` was missing a case for `HsSplicedPat`, which caused
incorrect renaming of TH-spliced pattern variables.

Fixes #13473.

Test Plan: make test TEST=T13473

Reviewers: facundominguez, austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13473

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

Gracious me.  Ever since this patch

  commit 37445780
  Author: Jan Stolarek <jan.stolarek@p.lodz.pl>
  Date:   Fri Jul 11 13:54:45 2014 +0200

      Injective type families

TcRnMonad.askNoErrs has been wrong. It looked like this

   askNoErrs :: TcRn a -> TcRn (a, Bool)
   askNoErrs m
    = do { errs_var <- newTcRef emptyMessages
         ; res  <- setErrsVar errs_var m
         ; (warns, errs) <- readTcRef errs_var
         ; addMessages (warns, errs)
         ; return (res, isEmptyBag errs) }

The trouble comes if 'm' throws an exception in the TcRn monad.
Then 'errs_var is never read, so any errors are simply lost.

This mistake was then propgated into DsMonad.dsWhenNoErrs, where
it gave rise to Trac #13642.

Thank to Ryan for narrowing it down so sharply.

I did some refactoring, as usual.

It turns out we were using two different sets of type variables when
reifying data family instances in Template Haskell. We were using the
tyvars quantifying over the instance itself for the LHS, but using the
tyvars quantifying over the data family instance constructor for the
RHS. This commit uses the instance tyvars for both the LHS and the RHS,
fixing #13618.

Test Plan: make test TEST=T13618

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13618

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

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13587

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

Summary:
After 8136a5cb (#11450), if you have
a class with an associated type:

```
class C a where
  type T a b
```

And you try to create an instance of `C` like this:

```
instance C Int where
  type T Int Char = Bool
```

Then it is rejected, since you're trying to instantiate the variable ``b`` with
something other than a type variable. But this restriction proves quite
onerous in practice, as it prevents you from doing things like this:

```
class C a where
  type T a (b :: Identity c) :: c

instance C Int where
  type T Int ('Identity x) = x
```

You have to resort to an auxiliary type family in order to define this now,
which becomes extremely tiring. This lifts this restriction and fixes #13398,
in which it was discovered that adding this restriction broke code in the wild.

Test Plan: ./validate

Reviewers: simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

The main goal is to easily allow the inline-c project (and
similar projects such as inline-java) to emit C/C++ files to
be compiled and linked with the current module.

Moreover, `addCStub` is removed, since it's quite fragile. Most
notably, the C stubs end up in the file generated by
`CodeOutput.outputForeignStubs`, which is tuned towards
generating a file for stubs coming from `capi` and Haskell-to-C
exports.

Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari

Reviewed By: dfeuer, bgamari

Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes

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

We need -dsuppress-uniques else this test keeps failing spuriously

Unfortunately this comes with a fair bit of implementation cost. Perhaps
some refactoring would help, but in the interest of getting 8.2 out the
door I'm pushing as-is.

While this doesn't have nearly the effect on compiler allocations
that D3166 has, it's still nothing to sneeze at. nofib shows,
```
------------------------------------------------------------------------
        Program               master           D3166            D3219
------------------------------------------------------------------------
        -1 s.d.                -----          -3.555%          -4.081%
        +1 s.d.                -----          +1.937%          +1.593%
        Average                -----          -0.847%          -1.285%
```

Test Plan: Validate

Reviewers: austin

Subscribers: thomie, simonmar

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

Here we rework the TcTypeable implementation to reuse KindRep bindings
when possible. This is an attempt at minimizing the impact of Typeable
binding generation by reducing the number of bindings that we produce.

It turns out that this produces some pretty reasonable compiler
allocations improvements. It seems to erase most of the increases
initially introduced by TTypeable in the testsuite. Moreover, nofib
shows,
```
        -1 s.d.                -----          -3.555%
        +1 s.d.                -----          +1.937%
        Average                -----          -0.847%
```

Here are a few of the high-scorers (ignore last column, which is for
D3219),
```
veritas
          Types             88800920         -18.945%         -21.480%

veritas
        Tactics            540766744         -27.256%         -27.338%

sched
           Main            567013384          -4.947%          -5.358%

listcompr
           Main            532300000          -4.273%          -4.572%

listcopy
           Main            537785392          -4.382%          -4.635%

anna
       BaseDefs           1984225032         -10.639%         -10.832%

```
as expected, these tend to be modules with either very many or very
large types.

Test Plan: Validate

Reviewers: austin, dfeuer

Subscribers: simonmar, dfeuer, thomie

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

When doing debug-printing it's really important that the free vars
of a type are printed with their uniques.  The IfaceTcTyVar thing
was a stab in that direction, but it only worked for TcTyVars, not
TyVars.

This patch does it properly, by keeping track of the free vars of the
type when translating Type -> IfaceType, and passing that down through
toIfaceTypeX.  Then when we find a variable, look in that set, and
translate it to IfaceFreeTyVar if so.  (I renamed IfaceTcTyVar to
IfaceFreeTyVar.)

Fiddly but not difficult.

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

This very small patch switches on sm_inline even in the InitialPhase
(aka "gentle" phase).   There is no reason not to... and the results
are astonishing.

I think the peformance of GHC itself improves by about 5%; and some
programs get much smaller, quicker.  Result: across the board
irmprovements in
compile time performance.  Here are the changes in perf/compiler;
the numbers are decreases in compiler bytes-allocated:

  3%   T5837
  7%   parsing001
  9%   T12234
  35%  T9020
  9%   T3064
  13%  T9961
  20%  T13056
  5%   T9872d
  5%   T9872c
  5%   T9872b
  7%   T9872a
  5%   T783
  35%  T12227
  20%  T1969

Plus in perf/should_run

  5%   lazy-bs-alloc

It wasn't as easy as it sounds: I did a raft of preparatory work in
earlier patches.  But it's great!

Reviewers: austin, bgamari

Subscribers: thomie

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

Bumps containers, time, and unix submodules.

This reverts commit c347a121.

The script I used is included as testsuite/driver/kill_extra_files.py,
though at this point it is for mostly historical interest.

Some of the tests in libraries/hpc relied on extra_files.py, so this
commit includes an update to that submodule.

One test in libraries/process also relies on extra_files.py, but we
cannot update that submodule so easily, so for now we special-case it
in the test driver.

They broke everything and the solution will be non-trivial.

This reverts commit 8ccbc2e5.
This reverts commit c8d995db.
This reverts commit 71533702.

We are now tracking the 2.0 branch.

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.

Test Plan: ./validate

Reviewers: bgamari, nomeata, austin, mpickering

Reviewed By: mpickering

Subscribers: mpickering, rwbarton, mboes, thomie

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

Summary:
There was a rather annoying corner case where splicing poly-kinded
Template Haskell declarations could trigger an error muttering about
`TypeInType` not being enabled, whereas the equivalent non-TH code would
compile without issue. This was causing by overzealous validity check in the
renamer, wherein failed to distinguish between two different `Exact` names
with the same `OccName`. As a result, it mistakenly believed some type
variables were being used as both type and kind variables simultaneously! Ack.

This avoids the issue by simply disabling the aforementioned validity check
for Exact names. Fixes #12503.

Test Plan: ./validate

Reviewers: austin, bgamari, goldfire

Subscribers: thomie

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

Summary:
The HsSyn prettyprinter tests patch 499e4382
broke the pretty-printing of Template Haskell-spliced class instances.

Test Plan: ./validate

Reviewers: RyanGlScott, austin, goldfire, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: thomie

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

Summary:
addCStub allows injecting C code in the current module to be included
in the final object file.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: bitonic, duncan, mboes, thomie

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

For some time now, type-level operators such as '+' have been treated as
type constructors, rahter than type variables.  This pathc fixes TH's
`lookupName` function to account for this behavior.

Reviewers: bgamari, austin, goldfire, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: Phyx, thomie

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

GHC Trac Issues: #11046

Summary:
The addition of rigorous pretty-printer tests
(499e4382) had the unfortunate
side-effect of revealing a bug in `hsSyn/Convert.hs` wherein instances are
_always_ qualified with an instance context, even if the context is empty. This
led to instances like this:

```
instance Foo Int
```

being pretty-printed like this!

```
instance () => Foo Int
```

We can prevent this by checking if the context is empty before adding an
HsQualTy to the type.

Also does some refactoring around HsForAllTys in `Convert` while I was in town.

Fixes #13183.

Test Plan: ./validate

Reviewers: goldfire, bgamari, austin, alanz

Reviewed By: alanz

Subscribers: mpickering, thomie

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

GHC Trac Issues: #13183

95dc6dc0 forgot to add `pragCompleteDName`
to the list of `templateHaskellNames`, which caused a panic if you actually
tried to splice a `COMPLETE` pragma using Template Haskell. This applies the
easy fix and augments the regression test to check for this in the future.

Reviewers: RyanGlScott, austin, goldfire, bgamari

Subscribers: thomie

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

GHC Trac Issues: #13098

Summary:
It turns out that D2974 broke this program
(see https://phabricator.haskell.org/rGHC729a5e452db5#58801):

```lang=haskell
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where

import GHC.Exts (Constraint)

$([d| data Dec13 :: (* -> Constraint) -> * where
        MkDec13 :: c a => a -> Dec13 c
    |])
```

This was actually due to a long-standing bug in `hsSyn/Convert` that put
unnecessary `forall`s in front of GADT constructors that didn't have any
explicitly quantified type variables.

This cargo-cults the code in `Convert` that handles `ForallT` and adapts
it to `ForallC`. Fixes #13123 (for real this time).

Test Plan: make test TEST=T13123

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #13123