Don't build old-{time,locale} and haskell{98,2010}

Summary:
As discussed on ghc-devs@haskell.org and the trac ticket, we're removing
these packages from the 7.10 release as they no longer work correctly,
and can't easily be made to properly follow the standard as `base`
changes over time.

This does not remove the packages from the tree, only the build system.

https://www.haskell.org/pipermail/ghc-devs/2014-November/007357.html

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

Test Plan: iiam

Reviewers: hvr, ekmett

Reviewed By: hvr, ekmett

Subscribers: thomie, carter

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

GHC Trac Issues: #9590
Delete old-{time,locale} and haskell{98,2010}

Summary:
Depends on D510. This is the final blow and removes them from
the tree completely.

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

Test Plan: I looked really hard but didn't see them.

Reviewers: hvr, ekmett

Subscribers: thomie, carter

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

GHC Trac Issues: #9590
Hide `Data.OldList` module

Summary:
The `Data.OldList` module was originally created in
3daf0023d2dcf7caf85d61f2dc177f8e9421b2fd to provide a way to access the
original list-specialised functions from `Data.List`. It was also made
an exposed module in order to facilitate adapting the
`haskell2010`/`haskell98` packages. However, since the
`haskell2010`/`haskell98` packages were dropped, we no longer need to
expose `Data.OldList`.

Depends on D511

Reviewers: ekmett, austin

Reviewed By: ekmett, austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D513
Export scanl' from Data.OldList and Data.List

Summary: Fixes #9368

Reviewers: nomeata, hvr, ekmett, austin

Reviewed By: ekmett, austin

Subscribers: thomie, carter

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

GHC Trac Issues: #9368
Add flag `-fwarn-missing-exported-sigs`

Summary: add `-fwarn-missing-exported-sigs` to only warn about missing signatures if the name is exported

Test Plan: validate, see testsuite/tests/warnings/should_compile/T2526.hs

Reviewers: ezyang, austin, thomie

Reviewed By: austin, thomie

Subscribers: ezyang, thomie, carter

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

GHC Trac Issues: #2526

Conflicts:
	docs/users_guide/7.10.1-notes.xml
Implement #5462 (deriving clause for arbitrary classes)

Summary: (this has been submitted on behalf on @dreixel)

Reviewers: simonpj, hvr, austin

Reviewed By: simonpj, austin

Subscribers: goldfire, thomie, carter, dreixel

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

GHC Trac Issues: #5462
Unbreak build (fallout from 067f1e4f20e)

Signed-off-by: Austin Seipp <austin@well-typed.com>
Revert change to alias handling in ppLlvmGlobal introduced in d87fa34, which requires LLVM 3.6.

Signed-off-by: Austin Seipp <austin@well-typed.com>
Rewrite Note [Deriving any class]

Phrases like “Currently, you can...” are going to sound strange in a few
years; I rephrased the note to sound less like a proposal and more like
an explanation.
Comments only
Rejig builders for pattern synonyms, especially unlifted ones

When a pattern synonym is for an unlifted pattern, its "builder" would
naturally be a top-level unlifted binding, which isn't allowed.  So we
give it an extra Void# argument.

Our Plan A involved then making *two* Ids for these builders, with
some consequential fuss in the desugarer.  This was more pain than I
liked, so I've re-jigged it.

 * There is just one builder for a pattern synonym.

 * It may have an extra Void# arg, but this decision is signalled
   by the Bool in the psBuilder field.

   I did the same for the psMatcher field.

   Both Bools are serialised into interface files, so there is
   absolutely no doubt whether that extra Void# argument is required.

 * I renamed "wrapper" to "builder".  We have too may "wrappers"

 * In order to deal with typecchecking occurrences of P in expressions,
   I refactored the tcInferId code in TcExpr.

All of this allowed me to revert 5fe872
   "Apply compulsory unfoldings during desugaring, except for `seq` which is special."
which turned out to be a rather messy hack in DsBinds
Move all the zonk/tidy stuff together into TcMType (refactoring only)
Implement full co/contra-variant subsumption checking (fixes Trac #9569)

This is a pretty big patch, but which substantially iproves the subsumption
check.  Trac #9569 was the presenting example, showing how type inference could
depend rather delicately on eta expansion.  But there are other less exotic
examples; see Note [Co/contra-variance of subsumption checking] in TcUnify.

The driving change is to TcUnify.tcSubType.  But also

* HsWrapper gets a new constructor WpFun, which behaves very like CoFun:
       if     wrap1 :: exp_arg <= act_arg
              wrap2 :: act_res <= exp_res
       then   WpFun wrap1 wrap2 : (act_arg -> arg_res) <= (exp_arg -> exp_res)

* I generalised TcExp.tcApp to call tcSubType on the result,
  rather than tcUnifyType.  I think this just makes it consistent
  with everything else, notably tcWrapResult.

As usual I ended up doing some follow-on refactoring

* AmbigOrigin is gone (in favour of TypeEqOrigin)
* Combined BindPatSigCtxt and PatSigCxt into one
* Improved a bit of error message generation
Put the decision of when a unification variable can unify with a polytype

This was being doing independently in two places. Now it's done in one
place, TcType.canUnifyWithPolyType
Make the on-the-fly unifier defer forall/forall unification

This has to be done by the full constraint solver anyway, and it's
rare, so there's really no point in doing it twice.  This change
just deletes some (tricky) code.
Fix a latent promotion bug in TcSimplify.simplifyInfer

We weren't promoting enough type variables, with unpredictable consequences.
The new code is, if anything, simpler.
Remove TcMType from compiler_stage2_dll0_MODULES

I can't say I really understand this DLL-split thing, but the build fails
if I don't remove TcMType here.

I've put this in a commit on its own, but it's a knock-on effect of the
immediately preceding wave of typechecker changes
Test Trac #9318
Trac #9222 is actually an ambiguous type, now detected
Delete duplicated tests