1. 18 Feb, 2018 1 commit
• Add valid refinement substitution suggestions for typed holes · 918c0b39
Matthías Páll Gissurarson authored
```This adds valid refinement substitution suggestions for typed holes and
documentation thereof.

Inspired by Agda's refinement facilities, this extends the typed holes
feature to be able to search for valid refinement substitutions, which
are substitutions that have one or more holes in them.

When the flag `-frefinement-level-substitutions=n` where `n > 0` is
passed, we also look for valid refinement substitutions, i.e.
substitutions that are valid, but adds more holes. Consider the
following:

f :: [Integer] -> Integer
f = _

Here the valid substitutions suggested will be (with the new
`-funclutter-valid-substitutions` flag for less verbosity set):

```
Valid substitutions include
f :: [Integer] -> Integer
product :: forall (t :: * -> *).
Foldable t => forall a. Num a => t a -> a
sum :: forall (t :: * -> *).
Foldable t => forall a. Num a => t a -> a
maximum :: forall (t :: * -> *).
Foldable t => forall a. Ord a => t a -> a
minimum :: forall (t :: * -> *).
Foldable t => forall a. Ord a => t a -> a
head :: forall a. [a] -> a
(Some substitutions suppressed; use -fmax-valid-substitutions=N or
-fno-max-valid-substitutions)
```

When the `-frefinement-level-substitutions=1` flag is given, we
additionally compute and report valid refinement substitutions:

```
Valid refinement substitutions include
foldl1 _ :: forall (t :: * -> *).
Foldable t => forall a. (a -> a -> a) -> t a -> a
foldr1 _ :: forall (t :: * -> *).
Foldable t => forall a. (a -> a -> a) -> t a -> a
head _ :: forall a. [a] -> a
last _ :: forall a. [a] -> a
error _ :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack => [Char] -> a
errorWithoutStackTrace _ :: forall (a :: TYPE r). [Char] -> a
(Some refinement substitutions suppressed; use
-fmax-refinement-substitutions=N or -fno-max-refinement-substitutions)
```

Which are substitutions with holes in them. This allows e.g. beginners
to discover the fold functions and similar.

We find these refinement suggestions by considering substitutions that
don't fit the type of the hole, but ones that would fit if given an
additional argument. We do this by creating a new type variable with
newOpenFlexiTyVarTy (e.g. `t_a1/m[tau:1]`), and then considering
substitutions of the type `t_a1/m[tau:1] -> v` where `v` is the type of
the hole. Since the simplifier is free to unify this new type variable
with any type (and it is cloned before each check to avoid
side-effects), we can now discover any identifiers that would fit if
given another identifier of a suitable type. This is then generalized
so that we can consider any number of additional arguments by setting
the `-frefinement-level-substitutions` flag to any number, and then
considering substitutions like e.g. `foldl _ _` with two additional
arguments.

This can e.g. help beginners discover the `fold` functions.
This could also help more advanced users figure out which morphisms
they can use when arrow chasing.
Then you could write `m = _ . m2 . m3` where `m2` and `m3` are some
morphisms, and not only get exact fits, but also help in finding
morphisms that might get you a little bit closer to where you want to
go in the diagram.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

2. 08 Feb, 2018 1 commit
• Fix isDroppableCt (Trac #14763) · 6edafe3b
Simon Peyton Jones authored
```When finishing up an implication constraint, it's a bit tricky to
decide which Derived constraints to retain (for error reporting) and
which to discard.  I got this wrong in commit
f20cf982
(Remove wc_insol from WantedConstraints)

The particular problem in Trac #14763 was that we were reporting as an
error a fundep-generated constraint
(ex ~ T)
where 'ex' is an existentially-bound variable in a pattern match.
But this isn't really an error at all.

This patch fixes the problem. Indeed, since I had to understand
this rather tricky code, I took the opportunity to clean it up
and document better.  See
isDroppableCt :: Ct -> Bool
and Note [Dropping derived constraints]

I also removed wl_deriv altogether from the WorkList data type.  It
was there in the hope of gaining efficiency by not even processing
lots of derived constraints, but it has turned out that most derived
constraints (notably equalities) must be processed anyway; see
Note [Prioritise equalities] in TcSMonad.

The two are coupled because to decide which constraints to put in
wl_deriv I was using another variant of isDroppableCt.  Now it's much
simpler -- and perhaps even more efficient too.```
3. 26 Jan, 2018 2 commits
• Sort valid substitutions for typed holes by "relevance" · cbdea959
Matthías Páll Gissurarson authored
```This is an initial attempt at tackling the issue of how to order the
suggestions provided by the valid substitutions checker, by sorting
them by creating a graph of how they subsume each other. We'd like to
order them in such a manner that the most "relevant" suggestions are
displayed first, so that the suggestion that the user might be looking
for is displayed before more far-fetched suggestions (and thus also
displayed when they'd otherwise be cut-off by the
`-fmax-valid-substitutions` limit). The previous ordering was based on
the order in which the elements appear in the list of imports, which I
believe is less correlated with relevance than this ordering.

A drawback of this approach is that, since we now want to sort the
elements, we can no longer "bail out early" when we've hit the
`-fmax-valid-substitutions` limit.

Reviewers: bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie, carter

• Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
Joachim Breitner authored
```Ideally, I'd like to do

type EvTerm = CoreExpr

and the type checker builds the evidence terms as it goes. This failed,
becuase the evidence for `Typeable` refers to local identifiers that are
added *after* the typechecker solves constraints. Therefore, `EvTerm`
stays a data type with two constructors: `EvExpr` for `CoreExpr`
evidence, and `EvTypeable` for the others.

Delted `Note [Memoising typeOf]`, its reference (and presumably
relevance) was removed in 8fa4bf9a.

4. 18 Jan, 2018 1 commit
• Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
Matthías Páll Gissurarson authored
```This implements SPJ's suggestion on the ticket (#14273). We find the
relevant constraints (ones that whose free unification variables are all
mentioned in the type of the hole), and then clone the free unification
variables of the hole and the relevant constraints. We then add a
subsumption constraints and run the simplifier, and then check whether
all the constraints were solved.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #14273

5. 03 Jan, 2018 1 commit
6. 21 Dec, 2017 1 commit
• Refactor coercion holes · a492af06
Simon Peyton Jones authored
```In fixing Trac #14584 I found that it would be /much/ more
convenient if a "hole" in a coercion (much like a unification
variable in a type) acutally had a CoVar associated with it
rather than just a Unique.  Then I can ask what the free variables
of a coercion is, and get a set of CoVars including those
as-yet-un-filled in holes.

Once that is done, it makes no sense to stuff coercion holes
inside UnivCo.  They were there before so we could know the
kind and role of a "hole" coercion, but once there is a CoVar
we can get that info from the CoVar.  So I removed HoleProv
from UnivCoProvenance and added HoleCo to Coercion.

In summary:

* Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance

* Similarly in IfaceCoercion

* Make CoercionHole have a CoVar in it, not a Unique

* Make tyCoVarsOfCo return the free coercion-hole variables
as well as the ordinary free CoVars.  Similarly, remember
to zonk the CoVar in a CoercionHole

We could go further, and remove CoercionHole as a distinct type
altogther, just collapsing it into HoleCo.  But I have not done
that yet.```
7. 19 Dec, 2017 1 commit
8. 08 Nov, 2017 1 commit
• Minimise provided dictionaries in pattern synonyms · 2c2f3cea
Simon Peyton Jones authored
```Trac #14394 showed that it's possible to get redundant
constraints in the inferred provided constraints of a pattern
synonym.  This patch removes the redundancy with mkMinimalBySCs.

To do this I had to generalise the type of mkMinimalBySCs slightly.
And, to reduce confusing reversal, I made it stable: it now returns
its result in the same order as its input.  That led to a raft of
error message wibbles, mostly for the better.```
9. 19 Oct, 2017 1 commit
• Fix #14369 by making injectivity warnings finer-grained · 8846a7fd
Ryan Scott authored
```Summary:
Previously, GHC would always raise the possibility that a
type family might not be injective in certain error messages, even if
that type family actually //was// injective. Fix this by actually
checking for a type family's lack of injectivity before emitting
such an error message.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #14369

10. 11 Oct, 2017 2 commits
• Remove wc_insol from WantedConstraints · f20cf982
Simon Peyton Jones authored
```This patch is a pure refactoring, which I've wanted to do for
some time.  The main payload is

* Remove the wc_insol field from WantedConstraints;
instead put all the insolubles in wc_simple

* Remove inert_insols from InertCans
Instead put all the insolubles in inert_irreds

* Add a cc_insol flag to CIrredCan, to record that
the constraint is definitely insoluble

Reasons

* Quite a bit of code gets slightly simpler
* Fewer concepts to keep separate
* Insolubles don't happen at all in production code that is
just being recompiled, so previously there was a lot of
moving-about of empty sets

A couple of error messages acutally improved.```
• Typos in comments only · ab1a7583
Simon Peyton Jones authored
11. 25 Sep, 2017 1 commit
• Improve type-error reporting · 1b476ab5
Simon Peyton Jones authored
```This patch does two things:

* When reporting a hole, we now include its kind if the
kind is not just '*'.  This addresses Trac #14265

* When reporting things like "'a' is a rigid type varaible
bound by ...", this patch arranges to group the type variables
together, so we don't repeat the "bound by..." stuff endlessly```
12. 21 Sep, 2017 1 commit
• Also show types that subsume a hole as valid substitutions for that hole. · 1c920832
Matthías Páll Gissurarson authored
```This builds on the previous "Valid substitutions include..." functionality,
but add subsumption checking as well, so that the suggested valid substitutions
show not only exact matches, but also identifiers that fit the hole by virtue of
subsuming the type of the hole (i.e. being more general than the type of the
hole).

Building on the previous example, in the given program

```
ps :: String -> IO ()
ps = putStrLn

ps2 :: a -> IO ()
ps2 _ = putStrLn "hello, world"

main :: IO ()
main = _ "hello, world"
```

The results would be something like

```
• Found hole: _ :: [Char] -> IO ()
• In the expression: _
In the expression: _ "hello, world"
In an equation for ‘main’: main = _ "hello, world"
• Relevant bindings include main :: IO () (bound at t1.hs:8:1)
Valid substitutions include
ps :: String -> IO () (defined at t1.hs:2:1)
ps2 :: forall a. a -> IO () (defined at t1.hs:5:1)
putStrLn :: String -> IO ()
(imported from ‘Prelude’ at t1.hs:1:1
(and originally defined in ‘System.IO’))
fail :: forall (m :: * -> *). Monad m => forall a. String -> m a
(imported from ‘Prelude’ at t1.hs:1:1
(and originally defined in ‘GHC.Base’))
mempty :: forall a. Monoid a => a
(imported from ‘Prelude’ at t1.hs:1:1
(and originally defined in ‘GHC.Base’))
print :: forall a. Show a => a -> IO ()
(imported from ‘Prelude’ at t1.hs:1:1
(and originally defined in ‘System.IO’))
(Some substitutions suppressed;
use -fmax-valid-substitutions=N or -fno-max-valid-substitutions)
```
Signed-off-by: Matthías Páll Gissurarson <mpg@mpg.is>

Modified according to suggestions from Simon PJ

Accept tests that match the expectations, still a few to look better at

Swithced to using tcLookup, after sit down with SPJ at ICFP. Implications are WIP.

Now works with polymorphism and constraints!

We still need to merge the latest master, before we can make a patch.

Wrap the type of the hole, instead of implication shenanigans,

As per SPJs suggestion, this is simpler and feels closer to
what we actually want to do.

Updated tests with the new implementation

Remove debugging trace and update documentation

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

13. 19 Sep, 2017 1 commit
• compiler: introduce custom "GhcPrelude" Prelude · f63bc730
Herbert Valerio Riedel authored
```This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.

This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`

Reviewers: austin, goldfire, bgamari, alanz, simonmar

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari

14. 14 Sep, 2017 2 commits
• Fix #13909 by tweaking an error message. · 89c8d4d2
Richard Eisenberg authored
```GHC was complaining about numbers of arguments when the real
problem is impredicativity.

test case: typecheck/should_fail/T13909```
• Tidying could cause ill-kinded types · 8bf865d3
Simon Peyton Jones authored
```I found (Trac #14175) that the tidying we do when reporting
type error messages could cause a well-kinded type to become
ill-kinded. Reason: we initialised the tidy-env with a
completely un-zonked TidyEnv accumulated in the TcLclEnv
as we come across lexical type-varialbe bindings.

Solution: zonk them.

But I ended up refactoring a bit:

* Get rid of tcl_tidy :: TidyEnv altogether

* Instead use tcl_bndrs :: TcBinderStack
This used to contain only Ids, but now I've added those
lexically scoped TyVars too.

* Change names:
TcIdBinderStack -> TcBinderStack
TcIdBinder      -> TcBinder
extendTcIdBndrs -> extendTcBinderStack

* Now tcInitTidyEnv can grab those TyVars from the
tcl_bndrs, zonk, and tidy them.

The only annoyance is that I had to add TcEnv.hs-boot, to
break the recursion between the zonking code and the
TrRnMonad functions like addErrTc that call tcInitTidyEnv.
Tiresome, but in fact that file existed already.```
15. 09 Sep, 2017 1 commit
16. 12 Aug, 2017 1 commit
• Use NonEmpty lists to represent lists of duplicate elements · 7d699782
Ryan Scott authored
```Summary:
Three functions in `ListSetOps` which compute duplicate elements
represent lists of duplicates of `[a]`. This is a really bad way to go about
things, because these lists are guaranteed to always have at least one element
(the "representative" of the duplicates), and several places in the GHC API
call `head` (a partial function) on these lists of duplicates to retrieve the
representative.

This changes the representation of duplicates to `NonEmpty` lists instead,
which allow for many partial uses of `head` to be made total.

Fixes #13823.

Test Plan: ./validate

Reviewers: bgamari, austin, goldfire

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie

GHC Trac Issues: #13823

17. 01 Aug, 2017 1 commit
• Drop GHC 7.10 compatibility · c13720c8
Ryan Scott authored
```GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
8.0. This means we can delete gobs of code that was only used for GHC
7.10 support. Hooray!

Test Plan: ./validate

Reviewers: hvr, bgamari, austin, goldfire, simonmar

Reviewed By: bgamari

Subscribers: Phyx, rwbarton, thomie

18. 27 Jul, 2017 3 commits
• Track visibility in TypeEqOrigin · fb752133
Richard Eisenberg authored
```A type equality error can arise from a mismatch between
*invisible* arguments just as easily as from visible arguments.
But we should really prefer printing out errors from visible
arguments over invisible ones. Suppose we have a mismatch between
`Proxy Int` and `Proxy Maybe`. Would you rather get an error
between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
so, too.

There is a fair amount of plumbing with this one, but I think
it's worth it.

This commit introduces a performance regression in test
perf/compiler/T5631. The cause of the regression is not the
new visibility stuff, directly: it's due to a change from
zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
is nicely optimized (it fuses away), but zipWith3M is not.
There are other examples of functions that could be made faster,
so I've posted a separate ticket, #14037, to track these
improvements. For now, I've accepted the small (6.6%) regression.```
• Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
Richard Eisenberg authored
```The uo_thing field of TypeEqOrigin is used to track the
"thing" (either term or type) that has the type (kind) stored
in the TypeEqOrigin fields. Previously, this was sometimes a
proper Core Type, which needed zonking and tidying. Now, it
is only HsSyn: much simpler, and the error messages now use
the user-written syntax.

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

Test case: typecheck/should_fail/T13819```
• Improve error messages around kind mismatches. · 8e15e3d3
Richard Eisenberg authored
```Previously, when canonicalizing (or unifying, in uType) a
heterogeneous equality, we emitted a kind equality and used the
resulting coercion to cast one side of the heterogeneous equality.

While sound, this led to terrible error messages. (See the bugs
listed below.) The problem is that using the coercion built from
the emitted kind equality is a bit like a wanted rewriting a wanted.
The solution is to keep heterogeneous equalities as irreducible.

See Note [Equalities with incompatible kinds] in TcCanonical.

This commit also removes a highly suspicious switch to FM_SubstOnly
when flattening in the kinds of a type variable. I have no idea
why this was there, other than as a holdover from pre-TypeInType.
I've not left a Note because there is simply no reason I can conceive
of that the FM_SubstOnly should be there.

One challenge with this patch is that the emitted derived equalities
might get emitted several times: when a heterogeneous equality is
in an implication and then gets floated out from the implication,
the Derived is present both in and out of the implication. This
causes a duplicate error message. (Test case:
typecheck/should_fail/T7368) Solution: track the provenance of
Derived constraints and refuse to float out a constraint that has
an insoluble Derived.

Lastly, this labels one test (dependent/should_fail/RAE_T32a)
as expect_broken, because the problem is really #12919. The
different handling of constraints in this patch exposes the error.

This fixes bugs #11198, #12373, #13530, and #13610.

test cases:
typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}```
19. 07 Jun, 2017 1 commit
20. 02 Jun, 2017 1 commit
• Use lengthIs and friends in more places · a786b136
Ryan Scott authored
```While investigating #12545, I discovered several places in the code
that performed length-checks like so:

```
length ts == 4
```

This is not ideal, since the length of `ts` could be much longer than 4,
and we'd be doing way more work than necessary! There are already a slew
of helper functions in `Util` such as `lengthIs` that are designed to do
this efficiently, so I found every place where they ought to be used and
did just that. I also defined a couple more utility functions for list
length that were common patterns (e.g., `ltLength`).

Test Plan: ./validate

Reviewers: austin, hvr, goldfire, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: goldfire, rwbarton, thomie

21. 26 May, 2017 3 commits
• Typos in comments [ci skip] · 19c4203f
Gabor Greif authored
• Some tidying up of type pretty-printing · ad14efd5
Simon Peyton Jones authored
```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.```
• 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```
22. 13 Apr, 2017 1 commit
23. 12 Apr, 2017 1 commit
• Split up RnEnv into 4 modules, RnUnbound, RnUtils and RnFixity · e07cd507
Matthew Pickering authored
```Summary:
RnEnv contains functions which convertn RdrNames into Names.

RnUnbound contains helper functions for reporting and creating
unbound variables.

RnFixity contains code which maintains the fixity environent
whilst renaming.

RnUtils contains the other stuff in RnEnv.

Reviewers: austin, goldfire, bgamari

Subscribers: goldfire, rwbarton, thomie, snowleopard

24. 06 Apr, 2017 1 commit
25. 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

26. 30 Mar, 2017 1 commit
27. 29 Mar, 2017 2 commits
• Show valid substitutions for typed holes · 26c95f46
Matthías Páll Gissurarson authored
```The idea is to implement a mechanism similar to PureScript, where they
suggest which identifiers in scope would fit the given hole. In
PureScript, they use subsumption (which is what we would like here as
well). For subsumption, we would have to check each type in scope
whether the hole is a subtype of the given type, but that would require
`tcSubType` and constraint satisfiability checking. Currently,
`TcSimplify` uses a lot of functions from `TcErrors`, so that would
require more of a rewrite, I will hold on with that for now, and submit
the more simpler type equality version.

As an example, consider

```
ps :: String -> IO ()
ps = putStrLn

ps2 :: a -> IO ()
ps2 _ = putStrLn "hello, world"

main :: IO ()
main = _ "hello, world"
```

The results would be something like

```
• Found hole: _ :: [Char] -> IO ()
• In the expression: _
In a stmt of a 'do' block: _ "hello, world"
In the expression:
do _ "hello, world"
• Relevant bindings include
main :: IO () (bound at test.hs:13:1)
ps :: String -> IO () (bound at test.hs:7:1)
ps2 :: forall a. a  -> IO () (bound at test.hs:10:1)
Valid substitutions include
putStrLn :: String
-> IO () (imported from ‘Prelude’ at
test.hs:1:1-14
(and originally defined in
‘System.IO’))
putStr :: String
-> IO () (imported from ‘Prelude’ at
test.hs:1:1-14
(and originally defined in ‘System.IO’))
```

We'd like here for ps2 to be suggested as well, but for that we require
subsumption.

Reviewers: austin, bgamari, dfeuer, mpickering

Reviewed By: dfeuer, mpickering

Subscribers: mpickering, Wizek, dfeuer, rwbarton, thomie

• Fix ASSERT failure in TcErrors · f88ac374
Simon Peyton Jones authored
```This fixes Trac #13494, by improving

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Mon Mar 27 10:32:08 2017 +0100

Fix error-message suppress on given equalities

which in turn was a fix to #13446```
28. 27 Mar, 2017 1 commit
• Fix error-message suppress on given equalities · e0ad55f8
Simon Peyton Jones authored
```I'd got the logic slightly wrong when reporting type errors
for insoluble 'given' equalities.  We suppress insoluble givens
under some circumstances (see Note [Given errors]), but we then
suppressed subsequent 'wanted' errors because the (suppressed)
'given' error "won".  Result: no errors at all :-(.

This patch fixes it and
- Renames TcType.isTyVarUnderDatatype to the more
perspicuous TcType.isInsolubleOccursCheck

In doing this I realise that I don't understand why we need
to keep the insolubles partitioned out separately at all...
but that is for another day.```
29. 10 Mar, 2017 1 commit
• Improve error messages for skolems · 48d1866e
Simon Peyton Jones authored
```In error messages like this
• Couldn't match type ‘c’ with ‘f0 (a -> b)’
‘c’ is a rigid type variable bound by
the type signature for:
f :: ((a -> b) -> b) -> forall c. c -> a

we need to take case both to actually show that 'forall c',
and to make sure that its name lines with the 'c' in the
error message.

This has been shaky for some time, and this commit puts it on solid
ground.  See TcRnTypes: Note [SigSkol SkolemInfo]

The main changes are

* SigSkol gets an extra field that records the way in which the
type signature was skolemised.

* The type in SigSkol is now the /un/-skolemised version

* pprSkolemInfo uses the info to make the tidy type line up
nicely

Lots of error message wibbles!```
30. 26 Feb, 2017 1 commit
31. 07 Feb, 2017 1 commit
32. 03 Feb, 2017 1 commit
• 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.

In cases for which we don't have easy access to a DynFlags, we read from
'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