GitLab

There was an outright bug in MatchCon.matchOneCon, in the construction
of arg_tys.  Easily fixed.  It never showed up becuase the arg_tys are
only used in WildPats, and they in turn seldom have their types looked
(except by hsPatType).  So I can't make a test case for htis.

While I was investigating, I added a bit of clarifation and
invariant-checking to dataConInstOrigArgTys and dataConInstArgTys

This came up in an email exchange with Duncan Coutts in May 2007.
If a function is marked NOINLINE there is really no point in 
doing a worker/wrapper split, because the wrapper will never
be inlined.

This patch fixes a plain bug in the specialiser (rhs_bndrs instead
of rhs_ids) which made GHC crash in obscure cases.  

It exposed a case in which we might not do all possible specialisation;
see Note [Specialisation shape].  It's not an important case, but I've
added a warning in DEBUG mode.

Trac #1402.  Test is spec003.hs

Fixes working in branches where that isn't true.

Two new -X flags, one for GADTs and one for relaxed polymorphic recursion

This also fixes a rather confusing error message that the Darcs folk 
tripped over.

We've often talked about having a separate flag for language extensions,
and now we have one. You can say

	-XImplicitParams
	-X=ImplicitParams
	-Ximplicit-params

as you like.  These replace the "-f" flags with similar names (though
the -f prefix will serve as a synonym for -X for a while).  

There's an optional "=", and the flag is normalised by removing hyphens
and lower-casing, so all the above variants mean the same thing.

The nomenclature is intended to match the LANGUAGE pramgas, which are
defined by Cabal.  So you can also say

	{-# LANGUAGE ImplicitParams #-}

But Cabal doesn't have as many language options as GHC does, so the -X
things are a superset of the LANGUAGE things.

The optional "=" applies to all flags that take an argument, so you can,
for example, say
	
	-pgmL=/etc/foo

I hope that's ok.  (It's an unforced change; just fitted in.)

I hope we'll add more -X flags, to replace the portmanteau -fglasgow-exts 
which does everything!  

I have updated the manual, but doubtless missed something.

I'd been too ambitious with error handling for 'deriving', and got it
entirely wrong.  This fixes it.  See extensive 
	Note [Exotic derived instance contexts]
in TcSimplify.  (Most of the extra lines are comments!)

This re-jig tides up the top-level simplification, and combines in one
well-commented function, approximateImplications, the rather ad-hoc
way of simplifying implication constraints during type inference.

Error messages get a bit better too.

Andy Gill writes: consider the following code

       f = g (case v of
                V a b -> a : t f)

where g is expensive. Liberate case will turn this into

       f = g (case v of
               V a b -> a : t (letrec f = g (case v of
                                             V a b -> a : f t)
                                in f)
             )
Yikes! We evaluate g twice. This leads to a O(2^n) explosion
if g calls back to the same code recursively.

This may be the same as Trac #1366.  

Consider the following code

     f = g (case v of
              V a b -> a : t f)

where g is expensive. Liberate case will turn this into

     f = g (case v of
             V a b -> a : t (letrec f = g (case v of
                                           V a b -> a : f t)
                              in f)
           )

Yikes! We evaluate g twice. This leads to a O(2^n) explosion
if g calls back to the same code recursively.

This happen sometimes in HPC, because every tick is a liberate-able case,
but is a general problem to case liberation (I think). 

Trac #1430 showed up quite a nasty bug in the handling of implication
constraints when we are *inferring* the type of a function.  
See Note [Inference and implication constraints]:

  We can't (or at least don't) abstract over implications.  But we might
  have an implication constraint (perhaps arising from a nested pattern
  match) like
  	C a => D a
  when we are now trying to quantify over 'a'.  Our best approximation
  is to make (D a) part of the inferred context, so we can use that to
  discharge the implication. Hence getImplicWanteds.

My solution is not marvellous, but it's better than before.  I transferred
function getDefaultableDicts from Inst to TcSimplify (since it's only
called there).  Many of the remaining 50 new lines are comments.  But
there is undoubtedly more code than before (sigh).

Test is tc228.  

See Trac #1426

I simplified the code, killed some unreachable blocks, and renamed it so that it corresponds more accurately with what is explained in the technical report

http://www.dsic.upv.es/docs/bib-dig/informes/etd-04042007-111431/papernew2.pdf

Also, fixed a bug related to newtypes in the pretty printer 

I guess we have a missing test... I'll add one