GitLab

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

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

As Trac #14605 showed, we can't defer a type error under a
'forall' (when unifying two forall types).

The fix is simple.

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.

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.

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

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

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.

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

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

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

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

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

GHC was complaining about numbers of arguments when the real
problem is impredicativity.

test case: typecheck/should_fail/T13909

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.

IOW, code compiles -Wnoncanonical-monoid-instances clean now

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

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

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

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

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.

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

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}

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

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

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.

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

This fixes a very simple typo in TcErrors.hs. I hope this is small
enough in scope to be accepted through GitHub.

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

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

I'd forgotten to add deferred bindings for user type
errors.  Fixes Trac #13487.

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

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

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

This had a few knock-on effects:

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

 * TypeMap now respects the Constraint/Type distinction

Finished by: bgamari

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

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

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

This fixes Trac #13494, by improving

   commit e0ad55f8
   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

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.

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!

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

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.

Updates haddock submodule.

Rebased and finished by: bgamari

Test Plan: validate

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

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #8440

This commit implements the proposal in
https://github.com/ghc-proposals/ghc-proposals/pull/29 and
https://github.com/ghc-proposals/ghc-proposals/pull/35.

Here are some of the pieces of that proposal:

* Some of RuntimeRep's constructors have been shortened.

* TupleRep and SumRep are now parameterized over a list of RuntimeReps.
* This
means that two types with the same kind surely have the same
representation.
Previously, all unboxed tuples had the same kind, and thus the fact
above was
false.

* RepType.typePrimRep and friends now return a *list* of PrimReps. These
functions can now work successfully on unboxed tuples. This change is
necessary because we allow abstraction over unboxed tuple types and so
cannot
always handle unboxed tuples specially as we did before.

* We sometimes have to create an Id from a PrimRep. I thus split PtrRep
* into
LiftedRep and UnliftedRep, so that the created Ids have the right
strictness.

* The RepType.RepType type was removed, as it didn't seem to help with
* much.

* The RepType.repType function is also removed, in favor of typePrimRep.

* I have waffled a good deal on whether or not to keep VoidRep in
TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
represented in RuntimeRep, and typePrimRep will never return a list
including
VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
imagine another design choice where we have a PrimRepV type that is
PrimRep
with an extra constructor. That seemed to be a heavier design, though,
and I'm
not sure what the benefit would be.

* The last, unused vestiges of # (unliftedTypeKind) have been removed.

* There were several pretty-printing bugs that this change exposed;
* these are fixed.

* We previously checked for levity polymorphism in the types of binders.
* But we
also must exclude levity polymorphism in function arguments. This is
hard to check
for, requiring a good deal of care in the desugarer. See Note [Levity
polymorphism
checking] in DsMonad.

* In order to efficiently check for levity polymorphism in functions, it
* was necessary
to add a new bit of IdInfo. See Note [Levity info] in IdInfo.

* It is now safe for unlifted types to be unsaturated in Core. Core Lint
* is updated
accordingly.

* We can only know strictness after zonking, so several checks around
* strictness
in the type-checker (checkStrictBinds, the check for unlifted variables
under a ~
pattern) have been moved to the desugarer.

* Along the way, I improved the treatment of unlifted vs. banged
* bindings. See
Note [Strict binds checks] in DsBinds and #13075.

* Now that we print type-checked source, we must be careful to print
* ConLikes correctly.
This is facilitated by a new HsConLikeOut constructor to HsExpr.
Particularly troublesome
are unlifted pattern synonyms that get an extra void# argument.

* Includes a submodule update for haddock, getting rid of #.

* New testcases:
  typecheck/should_fail/StrictBinds
  typecheck/should_fail/T12973
  typecheck/should_run/StrictPats
  typecheck/should_run/T12809
  typecheck/should_fail/T13105
  patsyn/should_fail/UnliftedPSBind
  typecheck/should_fail/LevPolyBounded
  typecheck/should_compile/T12987
  typecheck/should_compile/T11736

* Fixed tickets:
  #12809
  #12973
  #11736
  #13075
  #12987

* This also adds a test case for #13105. This test case is
* "compile_fail" and
succeeds, because I want the testsuite to monitor the error message.
When #13105 is fixed, the test case will compile cleanly.

No change in behaviour

This patch implements the display of constraints in the error message
for typed holes.

Test Plan: validate, read docs

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: simonpj, thomie

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

GHC Trac Issues: #10614