GitLab

I'm astonished that anything worked without this!

Fixes Trac #14339

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.

Ryan Scott authored Aug 17, 2017 and Ben Gamari committed Aug 17, 2017

Now that `mtl` and `parsec` are boot libraries, there's no need to
qualify various tests in the testsuite with `reqlib('mtl')` or
`reqlib('parsec')`.

Test Plan: make test TEST="T4809 tcfail126 T4355 tc232 tc223 tc220
tc217 tc183 T5303 DoParamM qq005 qq006 galois_raytrace T1074 mod133
T3787 T4316 prog011 drvfail006 drvfail008"

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

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

Summary:
For some asinine reason, we were suppressing warnings when
deriving associated type family instances with `DeriveAnyClass`. That seems
like a bad idea. Let's not do that.

Along the way, I noticed that the error contexts associated with these
newly emitted warnings were less than ideal, so I did some minor refactoring
to improve the story there.

Fixes #14094

Test Plan: ./validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14094

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

Summary:
`Typeable{1..7}` (type synonyms for the poly-kinded `Typeable`) have
been deprecated since GHC 7.8. They're now causing problems for users who try
to still work with them in legacy code, since they can no longer be used in
instances. To avoid this sort of confusion, let's just remove `Typeable{1..7}`
altogether. Resolves #14047.

Reviewers: bgamari, austin, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #14047

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

Simon Peyton Jones authored Aug 02, 2017 and Ryan Scott committed Aug 02, 2017

This was a simple slip, that gave rise to the bug reported in
comment:13 of Trac #14045.  We were supplying roles to mkAlgTyCon
that didn't match the tyvars.

Trac #13998 showed that default methods were getting bogus tyvar
binder visiblity info; and that it matters in the code genreated
by the default-method fill-in mechanism

* The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders
  with the right visibility info by getting TyConBinders from the
  class TyCon.  (Previously we made up visiblity info, but that
  caused #13998.)

* Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder]
  which can build correct forall binders for
    a) default methods (Trac #13998)
    b) data constructors
  This was originally BuildTyCl.mkDataConUnivTyVarBinders

* Move mkTyVarBinder, mkTyVarBinders from Type to Var

Summary:
Previously, one could experience error cascades with deriving clauses
when one class in a set of many failed to derive, causing the other derived
classes to be skipped entirely and resulting in other errors down the line.
The solution is to process each class in a data type's set of deriving clauses
individually, and engineer it so that failure to derive an individual class
within that set doesn't cancel out the others.

Test Plan: make test TEST="T10684 T12801"

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #10684, #12801

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

Test Plan: If it builds, ship it

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

Ryan Scott authored Jul 11, 2017 and Ben Gamari committed Jul 11, 2017

Although derived `Read`, `Show`, and `Generic` instances technically
don't //use// the record selectors of the data type for which an
instance is being derived, the derived code is affected by the
//presence// of record selectors. As a result, we should suppress
`-Wunused-binds` for those record selectors when deriving these classes.
This is accomplished by threading through more information from
`hasStockDeriving`.

Test Plan: make test TEST=T13919

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13919

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

Summary:
This amounts to using `exactTyCoVarsOfType` instead of
`tyCoVarsOfType` in the right place. I also fixed a similar issue for
`-XDatatypeContexts` while I was in town (but couldn't be bothered to add a
test for it).

Test Plan: make test TEST=T13813

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13813

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

This patch fixes a bad bug in the specialiser, which showed up as
Trac #13429.  When specialising an imported DFun, the specialiser could
generate a recusive loop where none existed in the original program.

It's all rather tricky, and I've documented it at some length in
   Note [Avoiding loops]

We'd encoutered exactly this before (Trac #3591) but I had failed
to realise that the very same thing could happen for /imported/
DFuns.

I did quite a bit of refactoring.

The compiler seems to get a tiny bit faster on
   deriving/perf/T10858
but almost all the gain had occurred before now; this
patch just pushed it over the line.

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

David Feuer authored Apr 01, 2017 and David Feuer committed Apr 01, 2017

There's no obvious reason to derive the definition of `showList`,
manually inlining the default definition. Let's just use
the default definition in the usual manner.

Garbage collect a few unused `RdrNames` from `PrelNames`:
`showList`, `showList__`, and `/=`.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

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

rwbarton authored Mar 31, 2017 and Ben Gamari committed Mar 31, 2017

It was expensive, as the simplifier runs for many iterations,
and probably not very useful.

Test Plan: harbormaster

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

David Feuer authored Mar 30, 2017 and David Feuer committed Mar 30, 2017

Make `Functor`, `Foldable`, and `Traversable` take advantage
of the case where the type parameter is phantom. In this case,

* `fmap _ = coerce`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (coerce x)`

For the sake of consistency and especially simplicity, make other types
with no data constructors behave the same:

* `fmap _ x = case x of`
* `foldMap _ _ = mempty`
* `traverse _ x = pure (case x of)`

Similarly, for `Generic`,

* `to x = case x of`
* `from x = case x of`

Give all derived methods for types without constructors appropriate
arities. For example,

```
    compare _ _ = error ...
```

rather than

```
    compare = error ...
```

Fixes #13117 and #13328

Reviewers: austin, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: ekmett, RyanGlScott, rwbarton, thomie

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

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!

Simon Peyton Jones authored Feb 28, 2017 and David Feuer committed Feb 28, 2017

When doing debug-printing it's really important that the free vars
of a type are printed with their uniques.  The IfaceTcTyVar thing
was a stab in that direction, but it only worked for TcTyVars, not
TyVars.

This patch does it properly, by keeping track of the free vars of the
type when translating Type -> IfaceType, and passing that down through
toIfaceTypeX.  Then when we find a variable, look in that set, and
translate it to IfaceFreeTyVar if so.  (I renamed IfaceTcTyVar to
IfaceFreeTyVar.)

Fiddly but not difficult.

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Simon Peyton Jones authored Feb 28, 2017 and David Feuer committed Feb 28, 2017

This very small patch switches on sm_inline even in the InitialPhase
(aka "gentle" phase).   There is no reason not to... and the results
are astonishing.

I think the peformance of GHC itself improves by about 5%; and some
programs get much smaller, quicker.  Result: across the board
irmprovements in
compile time performance.  Here are the changes in perf/compiler;
the numbers are decreases in compiler bytes-allocated:

  3%   T5837
  7%   parsing001
  9%   T12234
  35%  T9020
  9%   T3064
  13%  T9961
  20%  T13056
  5%   T9872d
  5%   T9872c
  5%   T9872b
  7%   T9872a
  5%   T783
  35%  T12227
  20%  T1969

Plus in perf/should_run

  5%   lazy-bs-alloc

It wasn't as easy as it sounds: I did a raft of preparatory work in
earlier patches.  But it's great!

Reviewers: austin, bgamari

Subscribers: thomie

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

Tamar Christina authored Feb 21, 2017 and Ben Gamari committed Feb 21, 2017

various perf tests have been broken over the course of the past few
months.  This updates the numbers.

Test Plan: ./validate

Reviewers: austin, bgamari

Subscribers: thomie, #ghc_windows_task_force

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

This bug was causing Trac #13297.

We were recomputing ds_tvs, and doing it wrongly (by omitting
variables that appear only in mtheta).  But actually plain 'tvs'
is just fine.  So code deleted, and bug fixed.

This patch fixes Trac #13272.  The general approach was fine, but
we were simply not generating the correct implication constraint
(in particular generating fresh unification variables).  I added
a lot more commentary to Note [Gathering and simplifying
constraints for DeriveAnyClass]

I'm still not very happy with the overall architecture.  It feels
more complicate than it should.

This at long last realizes the ideas for type-indexed Typeable discussed in A
Reflection on Types (#11011). The general sketch of the project is described on
the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
index to `TypeRep`,

    data TypeRep (a :: k)

This index allows the typechecker to reason about the type represented by the `TypeRep`.
This index representation mechanism is exposed as `Type.Reflection`, which also provides
a number of patterns for inspecting `TypeRep`s,

```lang=haskell
pattern TRFun :: forall k (fun :: k). ()
              => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                        (arg :: TYPE r1) (res :: TYPE r2).
                 (k ~ Type, fun ~~ (arg -> res))
              => TypeRep arg
              -> TypeRep res
              -> TypeRep fun

pattern TRApp :: forall k2 (t :: k2). ()
              => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
              => TypeRep a -> TypeRep b -> TypeRep t

-- | Pattern m...

Summary:
Currently, `DeriveAnyClass` has two glaring flaws:

* It only works on classes whose argument is of kind `*` or `* -> *` (#9821).
* The way it infers constraints makes no sense. It basically co-opts the
  algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or
  `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly
  constrained instances, which in extreme cases can lead to legitimate things
  failing to typecheck (#12594). Or even worse, it can trigger GHC panics
  (#12144 and #12423).

This completely reworks the way `DeriveAnyClass` infers constraints to fix
these two issues. It now uses the type signatures of the derived class's
methods to infer constraints (and to simplify them). A high-level description
of how this works is included in the GHC users' guide, and more technical notes
on what is going on can be found as comments (and a Note) in `TcDerivInfer`.

Fixes #9821, #12144, #12423, #12594.

Test Plan: ./validate

Reviewers: dfeuer, goldfire, simonpj, austin, bgamari

Subscribers: dfeuer, thomie

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

lukemaurer authored Feb 01, 2017 and David Feuer committed Feb 01, 2017

This major patch implements Join Points, as described in
https://ghc.haskell.org/trac/ghc/wiki/SequentCore.  You have
to read that page, and especially the paper it links to, to
understand what's going on; but it is very cool.

It's Luke Maurer's work, but done in close collaboration with Simon PJ.

This Phab is a squash-merge of wip/join-points branch of
http://github.com/lukemaurer/ghc. There are many, many interdependent
changes.

Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin

Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie

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

Rufflewind authored Jan 30, 2017 and Ben Gamari committed Jan 30, 2017

1. DoParamM requires the FlexibleContexts pragma now.

2. topHandler02 and topHandler03 were broken as timeout.py failed to
   translate signals to exit codes.

3. topHandler03 does not produce a consistent stderr, as it depends on
   what the user has /bin/sh set to.  dash writes "Terminated" whereas
   bash and zsh produce nothing in non-interactive mode.

4. The remaining tests are broken due to changes in the error message
   formatting.

Test Plan: validate

Reviewers: thomie, dfeuer, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: Phyx, dfeuer

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

Ben Gamari authored Jan 23, 2017 and Ben Gamari committed Jan 24, 2017

Bump the version of `Win32` to `2.5.0.0` which is a major update and includes
fixes for wrong alignments and wrong 64-bit types. Strangely enough this also
seems to resolve #12713, where `T10858` was failing due to too-low allocations.

The underlying type aliases have changed, so there is a potential
for user programs not to compile anymore, but the types were incorrect.

This also requires a bump in the `directory`, `Cabal`, and `process`
submodules.

Original author: Tamar Christina <tamar@zhox.com>

Test Plan: ./validate

Reviewers: bgamari, RyanGlScott, austin

Subscribers: hvr, RyanGlScott, thomie, #ghc_windows_task_force

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

Thomas Miedema authored Jan 22, 2017 and Ben Gamari committed Jan 22, 2017

The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.

Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.

    find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;

Tests containing inline comments or multiline strings are not modified.

Preparation for #12223.

Test Plan: Harbormaster

Reviewers: austin, hvr, simonmar, mpickering, bgamari

Reviewed By: mpickering

Subscribers: mpickering

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

GHC Trac Issues: #12223

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.

Sylvain Henry authored Nov 29, 2016 and Ben Gamari committed Nov 29, 2016

This patch reverts the change introduced with
587dcccf and restores the previous
default output of GHC (i.e., show source path and object path for each
compiled module).

The -fhide-source-paths flag can be used to hide these paths and reduce
the line
noise.

Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr

Reviewed By: hvr

Subscribers: thomie

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

GHC Trac Issues: #12851

Sylvain HENRY authored Nov 11, 2016 and Ben Gamari committed Nov 11, 2016

Reviewers: simonmar, mpickering, austin, bgamari

Reviewed By: bgamari

Subscribers: mpickering, nomeata, thomie

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

GHC Trac Issues: #12807

Ryan Scott authored Nov 10, 2016 and Ben Gamari committed Nov 10, 2016

When `GeneralizedNewtypeDeriving` is used with a type class that has no
methods, it will generate a redundant context, and as a result, it can
trigger warnings when compiled with `-Wredundant-constraints`. This is a
simple change in behavior to check beforehand if a class has methods
when deriving it with GND, and if it has no methods, avoid inferring the
redundant context.

Beware that the test for #6088, which used to be expected to fail, now
compiles without issue since it doesn't infer a problematic instance
context.

Thanks to Simon Peyton Jones for doing the necessary refactoring in
f05d685a.

Fixes #12814.

Test Plan: ./validate

Reviewers: goldfire, rwbarton, simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #12814

Summary:
This implements the ability to derive associated type family instances
for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the
users' guide additions for how this works; I essentially follow the pattern
laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18.

Fixes #2721 and #8165.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: simonpj

Subscribers: mpickering, thomie

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

GHC Trac Issues: #2721, #8165

Ben Gamari authored Oct 16, 2016 and Ben Gamari committed Oct 17, 2016

Strangely the allocation numbers on Windows differ significantly from
those on Linux. Usually I would just update the number, but I would
really like to understand why this is the case. This is a rather large
deviation in the compilation of a program which really shouldn't have
any appreciable platform dependence.

Summary:
To fix this issue, we simply disable `RebindableSyntax` whenever we rename
the code generated from a deriving clause.

Fixes #12688.

Test Plan: make test TEST=T12688

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #12688