GitLab

With this change `Control.Monad.foldM` becomes an alias for
`Data.Foldable.foldlM`.

Reviewed By: austin, ekmett

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

Fixes Trac #9658

I'm not quite sure why these have improved following the previous
four commits, but I'm quite happy about it

This is preparing for a fix to Trac #9612. The idea is that insoluble
constraints are nice solid errors that we should not discard before
we have a chance to report them.  So TcRnTypes.dropDerivedWC now
keeps insoluble Derived constrains, and instead TcSimplify.solve_wanteds
filters them out

We get somewhat better error message for kind-equality failures too.

A slight downside is that to avoid *duplicate* kind-equality failures
when we float a kind-incompatible equality (e.g.  alpha:* ~ Int#),
I've disabled constraint-floating when there are insolubles.  But that
in turn makes a handful of error messages a little less informative;
good examples are mc21, mc22, mc25.  But I am re-jigging the
constraint floating machinery in another branch, which will make this
go back to the way it was before.

With this change, the linker status logging output such as

    Loading package ghc-prim ... linking ... done.
    Loading package integer-gmp ... linking ... done.
    Loading package base ... linking ... done.

is suppressed unless verbosity level is `-v2` or higher. This is done
to reduce the compiler message noise when TH is involved, which can
reduce the visibiliy of compile warnings.

Reviewed By: ekmett, austin

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

This patch fixes Trac #9580, in which the Coercible machinery succeeded
even though the relevant data constructor was not in scope.

As usual I got dragged into a raft of refactoring changes,
all for the better.

* Delete TcEvidence.coercionToTcCoercion (now unused)

* Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
  and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
  (They both return TcCoercions.)

* tcInstNewTyConTF_maybe also gets more convenient type,
  which improves TcInteract.getCoercibleInst

* Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
  (as well as in tcInstNewTyConTF_maybe)

* Improve error report for Coercible errors, when data familes
  are involved  Another use of tcLookupDataFamInst

* In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
  local hacky code

* Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
  with eta-reduced newtypes, using
  (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX

Some small refactoring of TcSMonad.matchFam.

This commit updates several submodules in order to bump
the upper bounds on `base` of most boot packages

Moreover, this updates some of the test-suite cases which have
version numbers hardcoded within.

However, I'm not sure if this commit didn't introduce the following
two test-failures

   ghc-api  T8628 [bad stdout] (normal)
   ghc-api  T8639_api [bad stdout] (normal)

This needs investigation

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

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

Came up on GHC users list

This patch corrects an egregious error introduced by:

  commit 022f8750
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Thu May 15 16:07:04 2014 +0100

    Refactoring around TyCon.isSynTyCon

    * Document isSynTyCon better
    * Add isTypeSyonymTyCon for regular H98 type synonyms
    * Use isTypeSynonymTyCon rather than isSynTyCon where
      the former is really intended

At this particular spot in TcValidity we really do mean
isSynTyCon and not isTypeSynonymTyCon.

Fixes Trac #9433

Summary:
Previously, GHC would look for instances of wired-in packages in the
in-memory package database and null out the version number.  This was
necessary when the sourcePackageId was used to determine the linker
symbols; however, we now use a package key, so only that needs to be
updated.

Long-term, we can remove this hack by ensuring that Cabal actually records
the proper package key in the database.  This will also fix an unrelated
hack elsewhere.

Keeping version numbers means that wired in packages get rendered differently
when output by GHC.  This is the source of all the test-case output changes.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: hvr, austin

Subscribers: simonmar, ezyang, carter

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

* Deprecate -XOverlappingInstances

* Update test suite.  Several tests even had entirely unnecessary
  uses of -XOverlappingInstances

* Update user manual with a careful description of the instance
  resolution story

* Fix an outright bug in the handling of duplidate instances in GHCi,
  which are meant to silently overwrite the earlier duplicate. The
  logic was right for family instances but was both more complicated,
  and plain wrong, for class instances.  (If you are interested, the
  bug was that we were eliminating the duplicate from the InstEnv, but
  not from the [ClsInst] held in tcg_insts.)  Test is ghci044a.

Fixes Trac #9357

In looking at Trac #9063 I decided to re-design the default
instances for associated type synonyms.  Previously it was all
jolly complicated, to support generality that no one wanted, and
was arguably undesirable.

Specifically

* The default instance for an associated type can have only
  type variables on the LHS.  (Not type patterns.)

* There can be at most one default instances declaration for
  each associated type.

To achieve this I had to do a surprisingly large amount of refactoring
of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
of the LHS patterns.

That change in HsDecls has a (trivial) knock-on effect in Haddock, so
this commit does a submodule update too.

The net result is good though.  The code is simpler; the language
specification is simpler.  Happy days.

Trac #9263 and #9264 are thereby fixed as well.

This covers things like
   Eq a => blah   and   (?x::Int) => blah
where there is just one predicate. Previously we used an ad-hoc
test to decide whether to parenthesise it, but acutally there is
a much simpler solution: just use the existing precedence mechamism.

This applies both to Type and HsType.

This was pretty obscure.  elemLocalRdrEnv was utterly wrong (replied
False when it should reply True) when given an Exact Name. That
doesn't happen often, but it does happen in the result of a TH splice.
The result was that an associated type didn't get a type variable that
lined up with its parent class (elemLocalRdrEnv is used in
RnTypes.bindHsTyVars), and that messed up the singletons package.

I've made a completely different test case to show up the bug:
indexed_types/should_fail/T9160

I also refactored RdrName.LocalRdrEnv to be a record with named
fields, which makes the code more robust and easy to understand.

The improvement is to report the inferred type in the error message,
as suggested in email on ghc-deves (10 Jun 14).

This was triggered by looking at Trac #9171. See
Note [Suggest -fprint-explicit-kinds] in TcErrors

Fixes Trac #9167

All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
thank you!

I reviewed the patch, started some tidying, up and then ended up in a huge
swamp of changes, not all of which I can remember now.  But:

* To suppress kind arguments when we have -fno-print-explicit-kinds,
    - IfaceTyConApp argument types are in a tagged list IfaceTcArgs

* To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.

* When printing data/type family instances for the user, I've made them
  print out an informative RHS, which is a new feature. Thus
        ghci> info T
        data family T a
        data instance T Int = T1 Int Int
        data instance T Bool = T2

* In implementation terms, pprIfaceDecl has just one "context" argument,
  of type IfaceSyn.ShowSub, which says
       - How to print the binders of the decl
         see note [Printing IfaceDecl binders] in IfaceSyn
       - Which sub-comoponents (eg constructors) to print

* Moved FastStringEnv from RnEnv to OccName

It all took a ridiculously long time to do.  But it's done!

We now display the foralls of a type if any of the type variables
is polykinded.  This put kind polymorphism "in your face" a bit more
often, but eliminates a lot of head scratching.

The user manual reflects the new behaviour.

The argument in Trac #9033 is very compelling: we should not report 20
errors, fix one, and have the other 19 disappear.  They were spurious
in the first place.

The fix was easy; do type-class defaulting uncondionally, rather than
only if there are no insoluble constraints.

See Note [When to do type-class defaulting] in TcSimplify.

Error messages generally improve, especially tc211 which actually
had an example of precisely this phenomenon.

In tidying up the flattener I introduced an error that no
regression test caught, giving rise to Trac #8978, #8979.
It shows up if you have a type synonym whose RHS mentions
type functions, such sas
     type family F a
     type T a = (F a, a)   -- This synonym isn't properly flattened

The fix is easy, but sadly the bug is in the released GHC 7.8.1

This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

(We might want to revisit this.)