GitLab

the worker/wrapper creates an artificial INLINE pragma, which caused CSE
to not do its work. We now recognize such artificial pragmas by using
`NoUserInline` instead of `Inline` as the `InlineSpec`.

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

(cherry picked from commit 8c5405f6)

Triggered by the changes in #13677, I ended up doing a bit of
refactoring in type pretty-printing.

* We were using TyOpPrec and FunPrec rather inconsitently, so
  I made it consisent.

* That exposed the fact that we were a bit undecided about whether
  to print
     a + b -> c + d   vs   (a+b) -> (c+d)
  and similarly
     a ~ [b] => blah  vs   (a ~ [b]) => blah

  I decided to make TyOpPrec and FunPrec compare equal
  (in BasicTypes), so (->) is treated as equal precedence with
  other type operators, so you get the unambiguous forms above,
  even though they have more parens.

  We could readily reverse this decision.
  See Note [Type operator precedence] in BasicTypes

* I fixed a bug in pretty-printing of HsType where some
  parens were omitted by mistake.

In Core, Constraint should be considered fully equal to
TYPE LiftedRep, in all ways. Accordingly, coreView should
unwrap Constraint to become TYPE LiftedRep. Of course, this
would be a disaster in the type checker.

So, where previously we used coreView in both the type checker
and in Core, we now have coreView and tcView, which differ only
in their treatment of Constraint.

Historical note: once upon a past, we had tcView distinct from
coreView. Back then, it was because newtypes were unwrapped in
Core but not in the type checker. The distinction is back, but
for a different reason than before.

This had a few knock-on effects:

 * The Typeable solver must explicitly handle Constraint to ensure
   that we produce the correct evidence.

 * TypeMap now respects the Constraint/Type distinction

Finished by: bgamari

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

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

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.

Updates a number of submodules.

See Note [TYPE] in TysPrim. There are still some outstanding
pieces in #11471 though, so this doesn't actually nail the bug.

This commit also contains a few performance improvements:

* Short-cut equality checking of nullary type syns

* Compare types before kinds in eqType

* INLINE coreViewOneStarKind

* Store tycon binders separately from kinds.

This resulted in a ~10% performance improvement in compiling
the Cabal package. No change in functionality other than
performance. (This affects the interface file format, though.)

This commit updates the haddock submodule.

Some modest refactoring, triggered in part by Trac #11051

* Kill off PatSynId, ReflectionId in IdDetails
  They were barely used, and only for pretty-printing

* Add helper function Id.mkExportedVanillaId, and use it

* Polish up OccName.isDerivedOccName, as a predicate for
  definitions generated internally by GHC, which we
  might not want to show to the user.

* Kill off unused OccName.mkDerivedTyConOcc

* Shorten the derived OccNames for newtype and data
  instance axioms

* A bit of related refactoring around newFamInstAxiomName

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

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.

After the changes, the three functions used to print type families
were identical, so they are refactored into one.

Original RHSs of data instance declarations are recreated and
printed in user error messages.

RHSs containing representation TyCons are printed in the
Coercion Axioms section in a typechecker dump.

Add vbar to the list of SDocs exported by Outputable.
Replace all text "|" docs with it.

Fixes #10839

Reviewers: goldfire, jstolarek, austin, bgamari

Reviewed By: jstolarek

Subscribers: jstolarek, thomie

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

GHC Trac Issues: #10839

This also needs to update the primitive/vector submodules in order to
relax upper bounds on ghc-prim.

Like in f8ba4b55, a mass-rewrite in testsuite/ via

  sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')

was performed.

This also relaxes a few upper bounds on base in the ghc.git repo;

This required a mass-rewrite in testsuite/

  sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')

because it turns out the testsuite is still sensitive to package version
changes.

This is the second attempt at merging D757.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing
stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T1969:    GHC allocates 19% more
 * T4801:    GHC allocates 13% more
 * T5321FD:  GHC allocates 13% more
 * T9675:    GHC allocates 11% more
 * T783:     GHC allocates 11% more
 * T5642:    GHC allocates 10% more

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might
be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I
have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Updates haddock submodule

Test Plan: Let Harbormaster validate

Reviewers: austin, hvr, goldfire

Subscribers: goldfire, thomie

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

GHC Trac Issues: #9858

This reverts commit bef2f03e.

This merge was botched

Also reverts haddock submodule.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T3294:   GHC allocates 110% more (filed #11030 to track this)
 * T1969:   GHC allocates 30% more
 * T4801:   GHC allocates 14% more
 * T5321FD: GHC allocates 13% more
 * T783:    GHC allocates 12% more
 * T9675:   GHC allocates 12% more
 * T5642:   GHC allocates 10% more
 * T9961:   GHC allocates 6% more

 * T9203:   Program allocates 54% less

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Requires update of the haddock submodule.

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

Show the minimal complete definition on :info in ghci. They
are shown like MINIMAL pragmas in code. If the minimal complete
definition is empty or only a specific method from a class is
requested, nothing is shown.

Reviewed By: simonpj, austin, thomie

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

This is needed because GHC 7.10.2 requires a minor version bump to base-4.8.1.0

Several test outputs needed base-4.8.1.0 replaced by base-4.8.2.0

We've accumulated enough to justify a minor version bump to 4.8.1.0,
but not enough to justify a major version bump yet as far as I can see.

This major version bump was made necessary by
f44333ea which changed the type
signatures of prefetch primops, as well as other changes
such as 051d694f turning `Any` into
an abstract closed type family.

Reviewed By: ekmett

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

Fixes Trac #9658

This commit updates several submodules in order to bump
the upper bounds on `base` of most boot packages

Moreover, this updates some of the test-suite cases which have
version numbers hardcoded within.

However, I'm not sure if this commit didn't introduce the following
two test-failures

   ghc-api  T8628 [bad stdout] (normal)
   ghc-api  T8639_api [bad stdout] (normal)

This needs investigation

Summary:
Previously, GHC would look for instances of wired-in packages in the
in-memory package database and null out the version number.  This was
necessary when the sourcePackageId was used to determine the linker
symbols; however, we now use a package key, so only that needs to be
updated.

Long-term, we can remove this hack by ensuring that Cabal actually records
the proper package key in the database.  This will also fix an unrelated
hack elsewhere.

Keeping version numbers means that wired in packages get rendered differently
when output by GHC.  This is the source of all the test-case output changes.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: hvr, austin

Subscribers: simonmar, ezyang, carter

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

All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
thank you!

I reviewed the patch, started some tidying, up and then ended up in a huge
swamp of changes, not all of which I can remember now.  But:

* To suppress kind arguments when we have -fno-print-explicit-kinds,
    - IfaceTyConApp argument types are in a tagged list IfaceTcArgs

* To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.

* When printing data/type family instances for the user, I've made them
  print out an informative RHS, which is a new feature. Thus
        ghci> info T
        data family T a
        data instance T Int = T1 Int Int
        data instance T Bool = T2

* In implementation terms, pprIfaceDecl has just one "context" argument,
  of type IfaceSyn.ShowSub, which says
       - How to print the binders of the decl
         see note [Printing IfaceDecl binders] in IfaceSyn
       - Which sub-comoponents (eg constructors) to print

* Moved FastStringEnv from RnEnv to OccName

It all took a ridiculously long time to do.  But it's done!

Many of the files modified are just wibbles to output, because now
tycons have roles attached to them, which are produced in the debugging
dumps.