1. 26 Jul, 2017 1 commit
2. 20 Jul, 2017 1 commit
3. 28 Jun, 2017 1 commit
• Fix constraint solving for forall-types · fae672f6
Simon Peyton Jones authored
```Trac #13879 showed that when we were trying to solve

(forall z1 (y1::z1). ty1)  ~  (forall z2 (y2:z2). ty2)

we'd end up spitting out z1~z2 with no binding site for them.
Those kind equalities need to be inside the implication.

I ended up re-factoring the code for solving forall-equalities.
It's quite nice now.```
4. 20 Jun, 2017 1 commit
5. 26 May, 2017 2 commits
• Typos in comments [ci skip] · 19c4203f
Gabor Greif authored
• 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```
6. 19 May, 2017 1 commit
• Ensure that insolubles are fully rewritten · 433b80de
Simon Peyton Jones authored
```I was alerted to this by Trac #12468 and #11325.  We were treating
insolubles (and "hole" constraints are treated as insoluble)
inconsistently.  In some places we were carefully rewriting them
e.g. Note [Make sure that insolubles are fully rewritten] in
TcCanonical.  But in TcSimplify we weren't feeding them into
the solver.

As a result, "hole" constraints were not being rewritten, which
some users found confusing, and I think rightly so.

This patch also fixes a bug in TcSMonad.emitInsoluble, in which two
different "hole" constriants could be treated (bogusly) as duplicates,
thereby losing one.```
7. 03 May, 2017 1 commit
• Fix #13333 by fixing the covar's type in ctEvCoercion · 09bf135a
Richard Eisenberg authored
```The change is noted in Note [Given in ctEvCoercion]. This patch
also adds a bit more commentary to TcFlatten, documenting some
key invariants of the flattening algorithm. While in the area,
I also removed some stale commentary from TcCanonical.```
8. 29 Apr, 2017 1 commit
9. 05 Apr, 2017 1 commit
• Replace Digraph's Node type synonym with a data type · 1831aed1
Matthew Pickering authored
```This refactoring makes it more obvious when we are constructing
a Node for the digraph rather than a less useful 3-tuple.

Reviewers: austin, goldfire, bgamari, simonmar, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie

10. 01 Mar, 2017 1 commit
• Upgrade UniqSet to a newtype · cbe569a5
David Feuer authored
```The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
has a key invariant `UniqFM` does not. For example, `fmap` over
`UniqSet` will generally produce nonsense.

* Upgrade `UniqSet` from a type synonym to a newtype.

* Use cached unique in `tyConsOfType` by replacing
`unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.

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

Reviewed By: niteria

Subscribers: thomie

11. 20 Feb, 2017 1 commit
12. 18 Feb, 2017 1 commit
• Generalize kind of the (->) tycon · b207b536
Ben Gamari authored
```This is generalizes the kind of `(->)`, as discussed in #11714.

This involves a few things,

* Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
binders,
(->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
(a :: TYPE r1) (b :: TYPE r2).
a -> b -> *
```

* Unsaturated applications of `(->)` are expressed as explicit
`TyConApp`s

* Saturated applications of `(->)` are expressed as `FunTy` as they are
currently

* Saturated applications of `(->)` are expressed by a new `FunCo`
constructor in coercions

* `splitTyConApp` needs to ensure that `FunTy`s are split to a
`TyConApp`
of `(->)` with the appropriate `RuntimeRep` arguments

* Teach CoreLint to check that all saturated applications of `(->)` are
represented with `FunTy`

At the moment I assume that `Constraint ~ *`, which is an annoying
source of complexity. This will
be simplified once D3023 is resolved.

Also, this introduces two known regressions,

`tcfail181`, `T10403`
=====================
Only shows the instance,

instance Monad ((->) r) -- Defined in ‘GHC.Base’

in its error message when -fprint-potential-instances is used. This is
because its instance head now mentions 'LiftedRep which is not in scope.
I'm not entirely sure of the right way to fix this so I'm just accepting
the new output for now.

T5963 (Typeable)
================

T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
fingerprint without the RuntimeRep variables that (->) expects. This
will be fixed with the merge of D2010.

===================

about 20%. This certainly hurts, but it's also not entirely unexpected:
the size of every function type grows with this patch and Haddock has a
lot of functions in its heap.```
13. 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

14. 10 Feb, 2017 2 commits
15. 09 Feb, 2017 1 commit
• Guard rewritableTyVarsOfType · a5a6c527
Simon Peyton Jones authored
```We only want to use rewriteableTyVarsOfType on CDictCan,
CFunEqCan (and maybe CIrredCan).  But not CTyEqCan.

But we were -- for insolubles.  So I narrowed the scope of
the insuluble kick-out.```
16. 06 Feb, 2017 1 commit
17. 03 Feb, 2017 2 commits
• Use tyCoVarsOfType for CTyEqCan in shouldSplitWD · afa409fa
Simon Peyton Jones authored
```An ASSERT failure in rewritableTyVars made me realise
that there was an outright bug in shouldSplitWD.  See
the long Note [Splitting WD constraints].```
• Ditch static flags · bbd3c399
Sylvain Henry authored
```This patch converts the 4 lasting static flags (read from the command
line and unsafely stored in immutable global variables) into dynamic
flags. Most use cases have been converted into reading them from a DynFlags.

'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
It's not perfect (not thread-safe) but it is still better as we can
set/unset these 4 flags before each run when using GHC API.

Rebased and finished by: bgamari

Test Plan: validate

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

Reviewed By: simonmar

Subscribers: thomie

GHC Trac Issues: #8440```
18. 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```
19. 25 Jan, 2017 1 commit
20. 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```
21. 18 Jan, 2017 2 commits
22. 12 Dec, 2016 1 commit
• Refactor pruning of implication constraints · 818e027e
Simon Peyton Jones authored
```We try to prune solved implication constraints, but it's a
bit tricky because of our desire to correctly report unused
'givens'.  This patch improves matters a bit... in tracig some
other bug I saw lots of empty constraints lying around!```
23. 01 Dec, 2016 1 commit
24. 28 Nov, 2016 1 commit
25. 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.

* 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.```
26. 31 Oct, 2016 1 commit
27. 27 Oct, 2016 1 commit
• Collect coercion variables, not type variables · f9308c2a
Simon Peyton Jones authored
```...when tracking which constraints are used.

Previously we were gathering type variables too, which meant that the
ics_need field was (stupidly) non-empty, which meant that we kept hold
of solved implications for no purpose.  Better just to get rid of them,
which setImplicationStatus is all ste up to to do.

No change in behaviour; a bit more efficient.```
28. 26 Oct, 2016 1 commit
• Remove -dtrace-level · 48876ae0
Matthew Pickering authored
```The flag was:

1. Not documented.
2. Only used as a boolean flag.
3. Has overlapping functionality with -dno-debug-output
4. My poll of #ghc concluded that people didn't know it existed.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

GHC Trac Issues: #12691```
29. 24 Oct, 2016 1 commit
• Prioritise class-level equality costraints · 1c4a39d3
Simon Peyton Jones authored
```This patch fixes Trac #12734 by prioritising the class-level
variants of equality constraints, namely (a~b) and (a~~b).

See comment:10 of Trac #12734 for a description of what
went wrong, and Note [Prioritise class equalities] in TcSMonad.

The fix is still not great, but it's a definite step forward, and
cures the particular problem.

Worth merging to 8.0.```
30. 21 Oct, 2016 2 commits
• Define emitNewWantedEq, and use it · e1fc5a33
Simon Peyton Jones authored
`This is just a minor refactoring`
• A collection of type-inference refactorings. · 3f5673f3
Simon Peyton Jones authored
```This patch does a raft of useful tidy-ups in the type checker.
I've been meaning to do this for some time, and finally made
time to do it en route to ICFP.

1. Modify TcType.ExpType to make a distinct data type,
InferResult for the Infer case, and consequential
refactoring.

2. Define a new function TcUnify.fillInferResult, to fill in
an InferResult. It uses TcMType.promoteTcType to promote
the type to the level of the InferResult.
See TcMType Note [Promoting a type]
This refactoring is in preparation for an improvement
to typechecking pattern bindings, coming next.

I flirted with an elaborate scheme to give better
higher rank inference, but it was just too complicated.
See TcMType Note [Promotion and higher rank types]

3. Add to InferResult a new field ir_inst :: Bool to say
whether or not the type used to fill in the
InferResult should be deeply instantiated.  See
TcUnify Note [Deep instantiation of InferResult].

4. Add a TcLevel to SkolemTvs. This will be useful generally

- it's a fast way to see if the type
variable escapes when floating (not used yet)

- it provides a good consistency check when updating a
unification variable (TcMType.writeMetaTyVarRef, the
level_check_ok check)

I originally had another reason (related to the flirting
in (2), but I left it in because it seems like a step in
the right direction.

5. Reduce and simplify the plethora of uExpType,
tcSubType and related functions in TcUnify.  It was
such an opaque mess and it's still not great, but it's
better.

6. Simplify the uo_expected field of TypeEqOrigin.  Richard
had generatlised it to a ExpType, but it was almost always
a Check type.  Now it's back to being a plain TcType which
is much, much easier.

7. Improve error messages by refraining from skolemisation when
it's clear that there's an error: see
TcUnify Note [Don't skolemise unnecessarily]

8. Type.isPiTy and isForAllTy seem to be missing a coreView check,

9. Kill off tcs_used_tcvs.  Its purpose is to track the
givens used by wanted constraints.  For dictionaries etc
we do that via the free vars of the /bindings/ in the
implication constraint ic_binds.  But for coercions we
just do update-in-place in the type, rather than
generating a binding.  So we need something analogous to
bindings, to track what coercions we have added.

That was the purpose of tcs_used_tcvs.  But it only
worked for a /single/ iteration, whereas we may have
multiple iterations of solving an implication.  Look
at (the old) 'setImplicationStatus'.  If the constraint
is unsolved, it just drops the used_tvs on the floor.
If it becomes solved next time round, we'll pick up
coercions used in that round, but ignore ones used in
the first round.

There was an outright bug.  Result = (potentialy) bogus
unused-constraint errors.  Constructing a case where this
actually happens seems quite trick so I did not do so.

Solution: expand EvBindsVar to include the (free vars of
the) coercions, so that the coercions are tracked in
essentially the same way as the bindings.

This turned out to be much simpler.  Less code, more
correct.

10. Make the ic_binds field in an implication have type
ic_binds :: EvBindsVar
ic_binds :: Maybe EvBindsVar
This is notably simpler, and faster to use -- less
testing of the Maybe.  But in the occaional situation
where we don't have anywhere to put the bindings, the
belt-and-braces error check is lost.  So I put it back
as an ASSERT in 'setImplicationStatus' (see the use of
'termEvidenceAllowed')

All these changes led to quite bit of error message wibbling```
31. 17 Oct, 2016 2 commits
32. 12 Oct, 2016 1 commit
```This patch implements choice (3) of comment:14 on Trac #12660.