1. 26 Jul, 2017 1 commit
2. 26 May, 2017 1 commit
• Re-engineer Given flatten-skolems · 8dc6d645
Simon Peyton Jones authored
```The big change here is to fix an outright bug in flattening of Givens,
albeit one that is very hard to exhibit.  Suppose we have the constraint
forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ...

Then
- we'll flatten the (F) b to a fsk, say  (F b ~ fsk1)
- we'll rewrite the (F b) inside the inner implication to 'fsk1'
- when we leave the outer constraint we are suppose to unflatten;
but that fsk1 will still be there
- if we re-simplify the entire outer implication, we'll re-flatten
the Given (F b) to, say, (F b ~ fsk2)
Now we have two fsks standing for the same thing, and that is very
wrong.

Solution: make fsks behave more like fmvs:
- A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv
- We "fill in" that meta-tyvar when leaving the implication
- The old FlatSkol form of TcTyVarDetails is gone completely
- We track the flatten-skolems for the current implication in
a new field of InertSet, inert_fsks.

See Note [The flattening story] in TcFlatten.

In doing this I found various other things to fix:

* I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't
needed.   But I added one in TcSimplify.floatEqualities, which does
the zonk precisely when it is needed.

* Trac #13674 showed up a case where we had
- an insoluble Given,   e.g.  a ~ [a]
- the same insoluble Wanted   a ~ [a]
We don't use the Given to rewwrite the Wanted (obviously), but
we therefore ended up reporting
Can't deduce (a ~ [a]) from (a ~ [a])
which is silly.

Conclusion: when reporting errors, make the occurs check "win"
See Note [Occurs check wins] in TcErrors```
3. 16 May, 2017 1 commit
4. 11 Apr, 2017 1 commit
5. 31 Mar, 2017 1 commit
• Clean up coreView/tcView. · 6575f4b6
Ben Gamari authored
```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

6. 07 Mar, 2017 1 commit
7. 18 Feb, 2017 1 commit
• Type-indexed Typeable · 8fa4bf9a
Ben Gamari authored
```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,

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

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.```
8. 14 Feb, 2017 1 commit
• Implement HasField constraint solving and modify OverloadedLabels · da493897
```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

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

9. 08 Feb, 2017 1 commit
10. 02 Feb, 2017 1 commit
11. 31 Jan, 2017 1 commit
• Use top-level instances to solve superclasses where possible · 748b7974
Daniel Haraj authored
```This patch introduces a new flag `-fsolve-constant-dicts` which makes the
constraint solver solve super class constraints with available dictionaries if
possible. The flag is enabled by `-O1`.

The motivation of this patch is that the compiler can produce more efficient
code if the constraint solver used top-level instance declarations to solve
constraints that are currently solved givens and their superclasses. In
particular, as it currently stands, the compiler imposes a performance penalty
on the common use-case where superclasses are bundled together for user
convenience. The performance penalty applies to constraint synonyms as
well. This example illustrates the issue:

```
{-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-}
module B where

class M a b where m :: a -> b

type C a b = (Num a, M a b)

f :: C Int b => b -> Int -> Int
f _ x = x + 1
```

Output without the patch, notice that we get the instance for `Num Int` by
using the class selector `p1`.

```
f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int
f =
\ (@ b_a1EB) (\$d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) ->
+ @ Int
(GHC.Classes.\$p1(%,%) @ (Num Int) @ (M Int b_a1EB) \$d(%,%)_a1EC)
eta1_B1
B.f1
```

Output with the patch, nicely optimised code!

```
f :: forall b. C Int b => b -> Int -> Int
f =
\ (@ b) _ _ (x_azg :: Int) ->
case x_azg of { GHC.Types.I# x1_a1DP ->
GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#)
}
```

Reviewers: simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: mpickering, rwbarton, thomie

GHC Trac Issues: #12791, #5835```
12. 23 Jan, 2017 1 commit
• Apply the right substitution in ty-fam improvement · 2b64e926
Simon Peyton Jones authored
```Trac #13135 showed that we were failing to apply the
correct substitution to the un-substituted tyvars during
type-family improvement using injectivity.  Specifically
in TcInteractlinjImproveEqns we need to use instFlexiX.

An outright bug, easy to fix.

Slight refactoring along the way.  The quantified tyars of the axiom are
readily to hand; we don't need to take the free tyvars of the LHS```
13. 25 Nov, 2016 3 commits
• Be a bit more selective about improvement · f8c966c7
Simon Peyton Jones authored
```This patch makes [W] constraints not participate in
improvement.   See Note [Do not do improvement for WOnly]

Removes some senseless work duplication in some cases (notably
Trac #12860); should not change behaviour.```
• Refactor functional dependencies a bit · eb55ec29
Simon Peyton Jones authored
```* Rename CoAxiom.Eqn = Pair Type to TypeEqn,
and use it for fundeps

* Use the FunDepEqn for injectivity, which lets us share a bit
more code, and (more important) brain cells

* When generating fundeps, take the max depth of the two
constraints.  This aimed at tackling the strange loop in
Trac #12860, but there is more to come for that.

* Improve pretty-printing with -ddump-tc-trace```
• Another major constraint-solver refactoring · 1eec1f21
Simon Peyton Jones authored
```This patch takes further my refactoring of the constraint
solver, which I've been doing over the last couple of months
in consultation with Richard.

It fixes a number of tricky bugs that made the constraint
solver actually go into a loop, including

Trac #12526
Trac #12444
Trac #12538

The main changes are these

* Flatten unification variables (fmvs/fuvs) appear on the LHS
of a tvar/tyvar equality; thus
fmv ~ alpha
and not
alpha ~ fmv

See Note [Put flatten unification variables on the left]
in TcUnify.  This is implemented by TcUnify.swapOverTyVars.

* Don't reduce a "loopy" CFunEqCan where the fsk appears on
the LHS:
F t1 .. tn ~ fsk
where 'fsk' is free in t1..tn.
See Note [FunEq occurs-check principle] in TcInteract

This neatly stops some infinite loops that people reported;
and it allows us to delete some crufty code in reduce_top_fun_eq.
And it appears to be no loss whatsoever.

As well as fixing loops, ContextStack2 and T5837 both terminate
when they didn't before.

* Previously we generated "derived shadow" constraints from
Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
generate a derived shadow from the same Wanted.

A big change in this patch is to have two kinds of Wanteds:
[WD] behaves like a pair of a Wanted and a Derived
[W]  behaves like a Wanted only
See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
field of a Wanted.

This turned out to be a lot simpler.  A [WD] gets split into a
[W] and a [D] in TcSMonad.maybeEmitShaodow.

See TcSMonad Note [The improvement story and derived shadows]

* Rather than have a separate inert_model in the InertCans, I've
put the derived equalities back into inert_eqs.  We weren't
gaining anything from a separate field.

* Previously we had a mode for the constraint solver in which it
would more aggressively solve Derived constraints; it was used
for simplifying the context of a 'deriving' clause, or a 'default'
delcaration, for example.

But the complexity wasn't worth it; now I just make proper Wanted
constraints.  See TcMType.cloneWC

* Don't generate injectivity improvement for Givens; see
Note [No FunEq improvement for Givens] in TcInteract

* solveSimpleWanteds leaves the insolubles in-place rather than
returning them.  Simpler.

I also did lots of work on comments, including fixing Trac #12821.```
14. 21 Nov, 2016 1 commit
15. 13 Nov, 2016 1 commit
• Kill Type pretty-printer · 6c0f10fa
Ben Gamari authored
```Here we consolidate the pretty-printing logic for types in IfaceType. We
need IfaceType regardless and the printer for Type can be implemented in
terms of that for IfaceType. See #11660.

Note that this is very much a work-in-progress. Namely I still have yet
to ponder how to ease the hs-boot file situation, still need to rip out
more dead code, need to move some of the special cases for, e.g., `*` to
the IfaceType printer, and need to get it to validate. That being said,
it comes close to validating as-is.

Test Plan: Validate

Reviewers: goldfire, austin

Subscribers: goldfire, thomie, simonpj

GHC Trac Issues: #11660```
16. 21 Oct, 2016 1 commit
17. 10 Oct, 2016 1 commit
• Orient improvement constraints better · b255ae7b
Simon Peyton Jones authored
```This patch fixes an infinite loop in the constraint solver,
shown up by Trac #12522.

The solution is /very/ simple: just reverse the orientation of the
derived constraints arising from improvement using type-family
injectivity.  I'm not very proud of the fix --- it seems fragile
--- but it has the very great merit of simplicity, and it works
fine.

See Note [Improvement orientation] in TcInteract, and some
discussion on the Trac ticket.```
18. 30 Sep, 2016 1 commit
• Fix a bug in occurs checking · 66a8c194
Simon Peyton Jones authored
```1. Trac #12593 exposed a long-standing bug in the occurs
checking machinery.  When unifying two type variables
a ~ b
where a /= b, we were assuming that there could be
no occurs-check error.  But there can: 'a' can occur
in b's kind!  When the RHS was a non-tyvar we used
occurCheckExpand, which /did/ look in kinds, but not
when the RHS was a tyvar.

This bug has been lurking ever since TypeInType, maybe
longer.  And it was present both in TcUnify (the on-the-fly
unifier), and in TcInteract.

I ended up refactoring both so that the tyvar/tyvar
path naturally goes through the same occurs-check as
non-tyvar rhss.  It's simpler and more robust now.

One good thing is that both unifiers now share
TcType.swapOverVars
TcType.canSolveByUnification
previously they had different logic for the same goals

2. Fixing this bug exposed another!  In T11635 we end
up unifying
(alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
Now that the occurs check is done for tyvars too, we
look inside beta's kind.  And then reject the program
becuase of the forall inside there.  But in fact that
forall is fine -- it does not count as impredicative
polymoprhism.   See Note [Checking for foralls]
in TcType.

3. All this fuss around occurrence checking forced me
to look at TcUnify.checkTauTvUpdate
and TcType.occurCheckExpand
There's a lot of duplication there, and I managed
to elminate quite a bit of it. For example,
checkTauTvUpdate called a local 'defer_me'; and then
called occurCheckExpand, which then used a very
similar 'fast_check'.

Things are better, but there is more to do.```
19. 28 Sep, 2016 1 commit
20. 20 Jul, 2016 1 commit
21. 23 Jun, 2016 1 commit
22. 22 Jun, 2016 1 commit
• Expand given superclasses more eagerly · ce97b729
Simon Peyton Jones authored
```This patch fixes Trac #12175, another delicate corner case of
Note [Instance and Given overlap] in TcInteract.

In #12175 we were not expanding given superclasses eagerly
enough. It was easy to fix, and is actually rather neater than
before.

See Note [Eagerly expand given superclasses] in TcCanonical.
The main change is to move the eager expansion of given superclasses
to canClassNC.```
23. 15 Jun, 2016 2 commits
• Major patch to introduce TyConBinder · e368f326
Simon Peyton Jones authored
```Before this patch, following the TypeInType innovations,
each TyCon had two lists:
- tyConBinders :: [TyBinder]
- tyConTyVars  :: [TyVar]

They were in 1-1 correspondence and contained
overlapping information.  More broadly, there were many
places where we had to pass around this pair of lists,
instead of a single list.

This commit tidies all that up, by having just one list of
binders in a TyCon:

- tyConBinders :: [TyConBinder]

The new data types look like this:

Var.hs:
data TyVarBndr tyvar vis = TvBndr tyvar vis
data VisibilityFlag = Visible | Specified | Invisible
type TyVarBinder = TyVarBndr TyVar VisibilityFlag

TyCon.hs:
type TyConBinder = TyVarBndr TyVar TyConBndrVis

data TyConBndrVis
= NamedTCB VisibilityFlag
| AnonTCB

TyCoRep.hs:
data TyBinder
= Named TyVarBinder
| Anon Type

Note that Var.TyVarBdr has moved from TyCoRep and has been
made polymorphic in the tyvar and visiblity fields:

type TyVarBinder = TyVarBndr TyVar VisibilityFlag
-- Used in ForAllTy
type TyConBinder = TyVarBndr TyVar TyConBndrVis
-- Used in TyCon

type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
-- Ditto, in interface files

There are a zillion knock-on changes, but everything
arises from these types.  It was a bit fiddly to get the
module loops to work out right!

Some smaller points
~~~~~~~~~~~~~~~~~~~
* Nice new functions
TysPrim.mkTemplateKiTyVars
TysPrim.mkTemplateTyConBinders
which help you make the tyvar binders for dependently-typed
TyCons.  See comments with their definition.

* The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
was making an assumption about the order of the kind variables in the
kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.```
• Re-add FunTy (big patch) · 77bb0927
Simon Peyton Jones authored
```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```
24. 18 May, 2016 1 commit
• Make inert_model and inert_eqs deterministic sets · fffe3a25
niteria authored
```The order inert_model and intert_eqs fold affects the order that the
typechecker looks at things. I've been able to experimentally confirm
that the order of equalities and the order of the model matter for
determinism. This is just a straigthforward replacement of
nondeterministic VarEnv for deterministic DVarEnv.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: thomie

GHC Trac Issues: #4012```
25. 28 Apr, 2016 1 commit
• Kill varSetElems in injImproveEqns · 82538f65
niteria authored
```We want to remove varSetElems at the source level because it
might be a source of nondeterminism. I don't think it introduces
nondeterminism here, but it's easy to do the same thing
deterministically for the same price.

instFlexiTcS :: [TKVar] -> TcS (TCvSubst, [TcType])
instFlexiTcS currently gives the range of the produced substitution
as the second element of the tuple, but it's not used anywhere
right now. If it started to be used in the code I'm modifying
it would cause nondeterminism problems.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari, simonmar, simonpj

Reviewed By: simonpj

Subscribers: thomie

GHC Trac Issues: #4012```
26. 22 Apr, 2016 1 commit
• Warn about simplifiable class constraints · 9421b0c7
Simon Peyton Jones authored
```Provoked by Trac #11948, this patch adds a new warning to GHC

-Wsimplifiable-class-constraints

It warns if you write a class constraint in a type signature that
can be simplified by an existing instance declaration.  Almost always
this means you should simplify it right now; type inference is very
fragile without it, as #11948 shows.

I've put the warning as on-by-default, but I suppose that if there are
howls of protest we can move it out (as happened for -Wredundant-constraints.

It actually found an example of an over-complicated context in CmmNode.

Quite a few tests use these weird contexts to trigger something else,
so I had to suppress the warning in those.

The 'haskeline' library has a few occurrences of the warning (which
I think should be fixed), so I switched it off for that library in
warnings.mk.

The warning itself is done in TcValidity.check_class_pred.

HOWEVER, when type inference fails we get a type error; and the error
suppresses the (informative) warning.  So as things stand, the warning
only happens when it doesn't cause a problem.  Not sure what to do
about this, but this patch takes us forward, I think.```
27. 15 Apr, 2016 1 commit
• Kill some unnecessary varSetElems · 928d7473
niteria authored
```When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
`tyCoVarsOfTypeList x`.

Why? If you look at the implementation:
```
tyCoVarsOfTypeList ty = runFVList \$ tyCoVarsOfTypeAcc ty
tyCoVarsOfType ty = runFVSet \$ tyCoVarsOfTypeAcc ty
```
they use the same helper function. The helper function returns a
deterministically ordered list and a set. The only difference
between the two is which part of the result they take. It is redundant
to take the set and then immediately convert it to a list.

This helps with determinism and we eventually want to replace the uses
of `varSetElems` with functions that don't leak the values of uniques.
This change gets rid of some instances that are easy to kill.

I chose not to annotate every place where I got rid of `varSetElems`
with a comment about non-determinism, because once we get rid of
`varSetElems` it will not be possible to do the wrong thing.

Test Plan: ./validate

Reviewers: goldfire, austin, simonmar, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

GHC Trac Issues: #4012```
28. 04 Apr, 2016 1 commit
• Don't infer CallStacks · 7407a66d
Eric Seidel authored
```We originally wanted CallStacks to be opt-in, but dealing with let
binders complicated things, forcing us to infer CallStacks. It turns
out that the inference is actually unnecessary though, we can let the
wanted CallStacks bubble up to the outer context by refusing to
quantify over them. Eventually they'll be solved from a given CallStack
or defaulted to the empty CallStack if they reach the top.

So this patch prevents GHC from quantifying over CallStacks, getting us
back to the original plan. There's a small ugliness to do with
PartialTypeSignatures, if the partial theta contains a CallStack
constraint, we *do* want to quantify over the CallStack; the user asked
us to!

Note that this means that

foo :: _ => CallStack
foo = getCallStack callStack

will be an *empty* CallStack, since we won't infer a CallStack for the
hole in the theta. I think this is the right move though, since we want
CallStacks to be opt-in. One can always write

foo :: (HasCallStack, _) => CallStack
foo = getCallStack callStack

to get the CallStack and still have GHC infer the rest of the theta.

Test Plan: ./validate

Reviewers: goldfire, simonpj, austin, hvr, bgamari

Reviewed By: simonpj, bgamari

Subscribers: bitemyapp, thomie

Projects: #ghc

GHC Trac Issues: #11573```
29. 15 Mar, 2016 1 commit
• Fix #11401. · 35d37ff8
eir@cis.upenn.edu authored
```This commit teaches shortCutReduction about Derived constraints.

[skip ci]```
30. 24 Feb, 2016 1 commit
• Address #11471 by putting RuntimeRep in kinds. · d8c64e86
eir@cis.upenn.edu authored
```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.)

31. 08 Feb, 2016 1 commit
32. 22 Jan, 2016 1 commit
• Default non-canonical CallStack constraints · 835a2a24
Eric Seidel authored
```Test Plan: `make test TEST=T11462`

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

Projects: #ghc

GHC Trac Issues: #11462```
33. 19 Jan, 2016 1 commit
• Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
niteria authored
```This adds sanity checks to `substTy` that implement:

> when calling substTy subst ty it should be the case that the in-scope
> set in the substitution is a superset of
> * The free vars of the range of the substitution
> * The free vars of ty minus the domain of the substitution

and replaces violators with unchecked version. The violators were found
by running the GHC test suite.

This ensures that I can work on this incrementally and that what I fix won't
be undone by some other change.

It also includes a couple of fixes that I've already done.

Test Plan: ./validate

Reviewers: simonmar, goldfire, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

GHC Trac Issues: #11371```
34. 18 Jan, 2016 2 commits
• Replace calls to `ptext . sLit` with `text` · b8abd852
Jan Stolarek authored
```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

• un-wire-in error, undefined, CallStack, and IP · a7b751db
Eric Seidel authored
```I missed a crucial step in the wiring-in process of `CallStack` in D861,
the bit where you actually wire-in the Name... This led to a nasty bug
where GHC thought `CallStack` was not wired-in and tried to fingerprint
it, which failed because the defining module was not loaded.

But we don't need `CallStack` to be wired-in anymore since `error` and
`undefined` no longer need to be wired-in. So we just remove them all.

Test Plan: `./validate` and `make slowtest TEST=tc198`

Reviewers: simonpj, goldfire, austin, hvr, bgamari

Reviewed By: simonpj, bgamari

Subscribers: goldfire, thomie

Projects: #ghc

GHC Trac Issues: #11331```
35. 16 Jan, 2016 1 commit
• Fix a number of subtle solver bugs · 9308c736
Simon Peyton Jones authored
```As a result of some other unrelated changes I found that
IndTypesPerf was failing, and opened Trac #11408.  There's
a test in indexed-types/should-compile/T11408.

The bug was that a type like
forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int
is in fact unambiguous, but it's a bit subtle to prove
that it is unambiguous.

In investigating, Dimitrios and I found several subtle
bugs in the constraint solver, fixed by this patch

* canRewrite was missing a Derived/Derived case.  This was
lost by accident in Richard's big kind-equality patch.

* Interact.interactTyVarEq would discard [D] a ~ ty if there
was a [W] a ~ ty in the inert set.  But that is wrong because
the former can rewrite things that the latter cannot.
Fix: a new function eqCanDischarge

* In TcSMonad.addInertEq, the process was outright wrong for
a Given/Wanted in the (GWModel) case.  We were adding a new
Derived without kicking out things that it could rewrite.
Now the code is simpler (no special GWModel case), and works
correctly.

* The special case in kickOutRewritable for [W] fsk ~ ty,
turns out not to be needed.  (We emit a [D] fsk ~ ty which
will do the job.

I improved comments and documentation, esp in TcSMonad.```
36. 07 Jan, 2016 1 commit