GitLab

While investigating something else I found that 'typeSize' was
allocating like crazy.  Stupid becuase it should allocate precisely
nothing!!

Turned out that it was because typeSize and coercionSize were mutually
recursive across module boundaries, and so could not benefit from the
CPR property.  To fix this I moved them both into TyCoRep.

It's not critical (because typeSize is really only used in
debug mode, but I tripped over and example (T5642) in which
typeSize was one of the biggest single allocators in all of GHC.
And it's easy to fix, so I did.

We only do newtype unwrapping for Coercible constraints if
the newtype's data constructor is in scope.  We were trying to
record the fact that the data constructor was thereby 'used', so
that an import statement would not be flagged as unnecsssary
(by -Wunused-imports).

But the code was simply wrong. It was wrong because it assumed
that only one level of unwrapping happened, whereas
tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers.
So we need to return a /list/ of data constructors that are used.

This entailed a bit of refactoring, as usual.

Fixes Trac #12067

This renames VisibilityFlag from

> data VisibilityFlag = Visible | Specified | Invisible

to

> data ArgFlag = Required | Specified | Inferred

The old name was quite confusing, because both Specified
and Invisible were invisible! The new names are hopefully clearer.

With TypeInType Richard combined ForAllTy and FunTy, but that was often
awkward, and yielded little benefit becuase in practice the two were
always treated separately.  This patch re-introduces FunTy.  Specfically

* New type
    data TyVarBinder = TvBndr TyVar VisibilityFlag
  This /always/ has a TyVar it.  In many places that's just what
  what we want, so there are /lots/ of TyBinder -> TyVarBinder changes

* TyBinder still exists:
    data TyBinder = Named TyVarBinder | Anon Type

* data Type = ForAllTy TyVarBinder Type
            | FunTy Type Type
            |  ....

There are a LOT of knock-on changes, but they are all routine.

The Haddock submodule needs to be updated too

Summary:
Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
statements in GHC.

Test Plan: ./validate

Reviewers: goldfire, austin, hvr, bgamari

Reviewed By: austin, hvr, bgamari

Subscribers: thomie

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

I've changed the functions to their nonDet equivalents and explained
why they're OK there. This allowed me to remove foldNameSet,
foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly.

Test Plan: ./validate, there should be no change in behavior

Reviewers: simonpj, simonmar, austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #4012

This is from Simon's suggestion:

* `tyCoVarsOfTypesAcc` is a terrible name for a function with a
  perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
  Similarly others

* `runFVList` is also terrible, but also has a decent type.
  Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).

* `someVars` could be `mkFVs :: [Var] -> FV`.

The free vars of `ty2` need to be in scope to satisfy the substitution
invariant.
As far as I can tell we don't have the free vars of `ty2` when
substituting, so unfortunately we have to compute them.

Test Plan: ./validate

Reviewers: austin, bgamari, simonpj, goldfire

Subscribers: thomie, simonmar

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

GHC Trac Issues: #11371

In particular, this allows correct tracking of specified/invisible
for variables in Haskell98 data constructors and in pattern synonyms.
GADT-syntax constructors are harder, and are left until #11721.

This was all inspired by Simon's comments to my fix for #11512,
which this subsumes.

Test case: ghci/scripts/TypeAppData

[skip ci]  (The test case fails because of an unrelated problem
fixed in the next commit.)

Several things here:

* Re-implement piResultTys so that its substitution has
  the correct in-scope set

  That means paying close attention to performance, since as we
  discovered in Trac #11371, it's a heavily used function and
  is often used on ordinary function types, with no foralls to
  worry about substituting.

* Kill off applyTys, which was just the same as piResultTys.

* Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
  rather than repeatedly calling piResultTy.

No change in functionality here, but greater clarity:

* In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
  We are already maintaining an in-scope set in the fe_subst field,
  so it's silly do to it twice.

  (This isn't strictly connected to the rest of this patch, but
  the nomenclature changes below affect the same code, so I put
  them together.)

* TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
  out what to do, but in fact we almost always know which of the
  two we are doing.  So:
    - define extendTvSubst, extendCvSubst
    - and use them

* Similar renamings in TyCoRep:
   - extendTCvSubstList        -->   extendTvSubstList
   - extendTCvSubstBinder      -->   extendTvSubstBinder
   - extendTCvSubstAndInScope  --> extendTvSubstAndInScope

* Add Type.extendTvSubstWithClone, extendCvSubstWithClone

* Similar nomenclature changes in Subst, SimplEnv, Specialise

* Kill off TyCoRep.substTelescope (never used)

tyConRolesRepresentational is just a version of tyConRolesX, but
specialised for a Representational argument. Saves a bit of extra
argument passing and pattern matching, and tyConRolesX was often
called when we knew the argument role was Representational.

Rather to my surprise this made the compiler allocate 5% less
for tests T9872{b,c,d}.  At least I think it's this commit.
Good thing, regardless.

This patch finally makes it possible to have explicit
foralls in an instance decl
   instance forall (a :: *). Eq a => Eq [a] where ...

This is useful to allow kind signatures or indeed
explicicit kind for-alls; see Trac #11519

I thought it would be really easy, because an instance
declaration already contains an actual HsSigType, so all
the syntactic baggage is there.  But in fact it turned
out that instance declarations were kind-checked a
little differently, because the body kind of the forall
is 'Constraint' rather than '*'.

So I fixed that.  There a slight kludge
(see Note [Body kind of a HsQualTy], but it's still a
significant improvement.

I also did the usual other round of refactoring,
improved a few error messages, tidied up comments etc.
The only significant aspect of all that was

  * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy
    These function names suggest that they do something
    complicated, but acutally they do nothing. So I
    killed them.

  * Swap the arg order of mkNamedBinder, just so that it is
    convenient to say 'map (mkNamedBinder Invisible) tvs'

  * I had to improve isPredTy, to deal with (illegal)
    types like
       (Eq a => Eq [a]) => blah
    See Note [isPeredTy complications] in Type.hs

Still to come: user manual documentation for the
instance-decl change.

This adds asserts to `substTys`, `substCo` and `substCos` in
the same spirit as already existing asserts on `substTy`, protecting
every possible entry point to `subst_ty` and `subst_co`.

I've replaced the violators with unchecked versions.

Test Plan: ./validate --slow

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11371

We really need to know the UnivCoProvenance to make sense
of UnivCos in debug output

Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`.  But for some time now we have function `text` that
does the same.  Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`.  The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`.  I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.

Test Plan: ./validate

Reviewers: bgamari, austin, goldfire, hvr, alanz

Subscribers: goldfire, thomie, mpickering

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

Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and
GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP
compatibility CPP-mess for good!

Reviewers: austin, goldfire, bgamari

Subscribers: goldfire, thomie, erikd

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

This may have performance implications.

This moves code around to more sensible places.

- Construction for CoAxiom is localised in FamInstEnv

- orphNamesOfxx moves to CoreFVs

- roughMatchTcs, instanceCantMatch moves to Unify

- mkNewTypeCo moves from Coercion to FamInstEnv, and is
  renamed mkNewTypeCoAxiom, which makes more sense

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.

This patch began as a modest refactoring of HsType and friends, to
clarify and tidy up exactly where quantification takes place in types.
Although initially driven by making the implementation of wildcards more
tidy (and fixing a number of bugs), I gradually got drawn into a pretty
big process, which I've been doing on and off for quite a long time.

There is one compiler performance regression as a result of all
this, in perf/compiler/T3064.  I still need to look into that.

* The principal driving change is described in Note [HsType binders]
  in HsType.  Well worth reading!

* Those data type changes drive almost everything else.  In particular
  we now statically know where

       (a) implicit quantification only (LHsSigType),
           e.g. in instance declaratios and SPECIALISE signatures

       (b) implicit quantification and wildcards (LHsSigWcType)
           can appear, e.g. in function type signatures

* As part of this change, HsForAllTy is (a) simplified (no wildcards)
  and (b) split into HsForAllTy and HsQualTy.  The two contructors
  appear when and only when the correponding user-level construct
  appears.  Again see Note [HsType binders].

  HsExplicitFlag disappears altogether.

* Other simplifications

     - ExprWithTySig no longer needs an ExprWithTySigOut variant

     - TypeSig no longer needs a PostRn name [name] field
       for wildcards

     - PatSynSig records a LHsSigType rather than the decomposed
       pieces

     - The mysterious 'GenericSig' is now 'ClassOpSig'

* Renamed LHsTyVarBndrs to LHsQTyVars

* There are some uninteresting knock-on changes in Haddock,
  because of the HsSyn changes

I also did a bunch of loosely-related changes:

* We already had type synonyms CoercionN/CoercionR for nominal and
  representational coercions.  I've added similar treatment for

      TcCoercionN/TcCoercionR

      mkWpCastN/mkWpCastN

  All just type synonyms but jolly useful.

* I record-ised ForeignImport and ForeignExport

* I improved the (poor) fix to Trac #10896, by making
  TcTyClsDecls.checkValidTyCl recover from errors, but adding a
  harmless, abstract TyCon to the envt if so.

* I did some significant refactoring in RnEnv.lookupSubBndrOcc,
  for reasons that I have (embarrassingly) now totally forgotten.
  It had to do with something to do with import and export

Updates haddock submodule.

I've run into situations where I need deterministic `tyVarsOfType` and
this implementation achieves that and also brings an algorithmic
improvement.  Union of two `VarSet`s takes linear time the size of the
sets and in the worst case we can have `n` unions of sets of sizes
`(n-1, 1), (n-2, 1)...` making it quadratic.

One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
in `SetLevels`. When we abstract type variables when floating we want
them to be abstracted in deterministic order.

Test Plan: harbormaster

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

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #4012

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

Now we use Array to store branches. This makes sense because we often
have to do random access (once inference is done). This also vastly
simplifies the awkward BranchList type.

This fixes #10837 and updates submodule utils/haddock.

For details see #6018, Phab:D202 and the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies

This patch also wires-in Maybe data type and updates haddock submodule.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar,
             carter

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

GHC Trac Issues: #6018

When doing strictness analysis, we need to look inside products.
To avoid unpacking infinitely, we must be careful about
infinite types.  That in turn is controlled by TyCon.checkRecTc.

For data families like
   data instance T (a,b) = MkT a (T b)
we want to unpack the thing recursively for types like
  T (Int, (Int, (Int, Int)))

This patch elaborates the checkRecTc mechanism in TyCon, to
maintain a *count* of how many times a TyCon has shown up,
rather than just a boolean.

A simple change, and a useful one.  Fixes Trac #10482.

This adds the significant Note [Decomposing equalities] to
TcCanonical, trying to sort out the various cases involved.

The only functional change this commit should make is a different
treatment of data families, which were wrong before (they could
be decomposed at role R, which is wrong).

During this commit, I tested to make sure that CoreLint actually
catches the Core error if the typechecker doesn't.

Test case: typecheck/should_fail/T10285

Whether to re-export the `<$>` non-method operator from `Prelude` wasn't
explicitly covered in the original AMP proposal[1], but it turns out that
not doing so forces most code that makes use of applicatives to import
`Data.Functor` or `Control.Applicative` just to get that operator into
scope.  To this end, it was proposed to add `<$>` to Prelude as well[2].

The down-side is that this increases the amount of redundant-import
warnings triggered, as well as the relatively minor issue of stealing
the `<$>` operator from the default namespace for good (although at this
point `<$>` is supposed to be ubiquitous anyway due to `Applicative`
being implicitly required into the next Haskell Report)

 [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
 [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161

Reviewed By: austin, ekmett

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

This is minor stuff triggered by Trac #10103.

* Fix outdated comments on tcView/coreView (we should really combine
  them with a new name, but I'll leave that slightly-disruptive change
  for now)

* Combine tcExpandTyCon_maybe and coreExpandTyCon_maybe (which were identical)
  into expandSynTyCon_maybe

* A few more comment fixups

Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.

Reviewers: austin, jstolarek, hvr, goldfire

Reviewed By: austin, jstolarek

Subscribers: thomie, goldfire

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

GHC Trac Issues: #9986

Universal coercions allow casting between arbitrary types, so it is a
good idea to keep track where they came from, which now we can do by
using the provenance field in `UnivCo`.

This is also handy for type-checker plugins that provide functionality
beyond what's expressible by GHC's standard coercions:  such plugins
can generate universal coercions, but they should still tag them,
so that if something goes wrong we can link the casts to the plugin.

Summary:
This is a rewrite of the algorithm to solve for Coercible "instances".

A preliminary form of these ideas is at
https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver

The basic idea here is that the `EqPred` constructor of `PredTree`
now is parameterised by a new type `EqRel` (where
`data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
now talk about nominal equality (the usual case) or representational
equality (the `Coercible` case).

This is a change from the previous
behavior where `Coercible` was just considered a regular class with
a special case in `matchClassInst`.

Because of this change, representational equalities are now
canonicalized just like nominal ones, allowing more equalities
to be solved -- in particular, the case at the top of #9117.

A knock-on effect is that the flattener must be aware of the
choice of equality relation, because the inert set now stores
both representational inert equalities alongside the nominal
inert equalities. Of course, we can use representational equalities
to rewrite only within another representational equality --
thus the parameterization of the flattener.

A nice side effect of this change is that I've introduced a new
type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
in the flattener.

This commit includes some refactoring as discussed on D546.
It also removes the ability of Deriveds to rewrite Deriveds.

This fixes bugs #9117 and #8984.

Reviewers: simonpj, austin, nomeata

Subscribers: carter, thomie

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

GHC Trac Issues: #9117, #8984

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

This change is just for naming uniformity with the existing downgradeRole