GitLab

This cleanup allows the following refactoring commit to avoid adding a
few `{-# LANGUAGE NondecreasingIndentation #-}` pragmas.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This replaces the previous `default-extensions` by per-file declared
`{-# LANGUAGE ... #-}` pragmas.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

The utils/hpc/*.hs code doesn't use any CPP statements anyway, so this
extensions was redundantly enabled to begin with.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This also removes the redundant `default-extensions` field in
`bin-package-db.cabal` and adds an `other-extensions` field instead.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This also makes ghc-pkg.cabal `default-extensions`-free

NB: Printing this commit via `git show --ignore-all-spaces` shows the
    only non-whitespaces changes are in `ghc-pkg.cabal`
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Haskell2010 implies (at least) EmptyDataDecls, ForeignFunctionInterface,
PatternGuards, DoAndIfThenElse, and RelaxedPolyRec.

This is a follow-up to dd92e217Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This is a first step towards eliminating `default-extensions` in favour of
per-file declared `{-# LANGUAGE ... #-}` pragmas.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

A strict (<$>) has been proposed numerous times. The first time
around[1] by Johan Tibell, and the last time around[2] by David
Luposchainsky. David's thread was able to avoid The Bikeshed Monster,
and his (<$!>) proposal received unanimous +1s all around.

This addresses #9099.

 [1]: http://www.haskell.org/pipermail/libraries/2013-November/021728.html
 [2]: http://www.haskell.org/pipermail/libraries/2014-April/022864.htmlAuthored-by: Alexander Berntsen <alexander@plaimi.net>
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This splits up Haddock up a bit to allow use of its parser (and in the
future perhaps more) without GHC dependency. It should build fine with
the regular work-flow but if you get problems with building Haddock then
please revert this and let me know.

isSynTyCon is true of type *family* TyCons, which *are* allowed
in TyConAppCo

In commit 83a003fc globalRegMaybe will be called but panics
for unregisterised compilers.

In an unregisterised compiler there are no global registers
so always return `Nothing`.

Fixes #9055.

mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot
be a type synonym.  This small patch fixes it.

That is why Lint didn't nail Trac #9102

This patch implements a simpler, and nicer, desugaring for
lazy pattern matching, fixing Trac #9098

This fixes Trac #9096

I wrote these when studying Trac #9090

this reverts 12332f1a. The error message changes when there are two
versions of transformers in the database, one of them hidden. That might
be a bug of its own, but for now lets make the test case succeed after a
fresh build. Affected developers should probably
$ ./inplace/bin/ghc-pkg unregister transformers-0.3.0.0

in order to get a reliable error message
(although the error message could be improved anyways to mention the
explicit package the module is imported with.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

The main effect of this patch is to preserve the evaluated-ness of
case binders and suchlike, to avoid spurious Lint complaints after
tidying.  See Note [Preserve evaluatedness] in CoreTidy.

Plus a bit of associated refactoring of tidyIdBndr, tidyLetBndr.

See Note [Mark evaluated arguments] in CoreUtils.

This is not a significant change, but avoids a spurious Lint complaint.

No change in functionality, just a cleaner story, with the RHS for
dictionary selectors being treated less specially than before.

This also updates the haskeline to upstream master to
accomodate the new transformers version

This is in pursuit of Trac #9063

The constraints for Functor don't line up 1-1 with the arguments
(they are fetched out from sub-terms of the type), but the surrounding
code was mistakenly assuming they were in 1-1 association.

My first attempt introduce a bug in -fprint-minimal-imports, but
fortunately a regression test caught it.

See TypeRep.pprUserForAll.  This just makes forall-printing a bit more
consistent.  In particular, I wasn't seeing the kind foralls when
displaying a CoAxiom or CoAxBranch

The output on T7939 is just possible a bit too verbose now, but even if so
that's an error in the right direction.

See Note [Un-warnable import decls] in RnNames.

Fixes Trac #9061.