GitLab

The advantages of this are
  (a) it's a step closer to getting -j working again (make -j works in
      an individual library, but not in libraries/ yet).
  (b) it's easier to hack on libraries: make dist/build/Foo.o
  (c) it's a step closer to getting HC bootstrapping again

The build system creates <lib>/GNUmakefile as part of 'make boot'.
This was chosen so as not to interfere with existing Makefiles, but
it's a bit of a hack.  (previously I used CabalMakefile, but that
means adding -f CabalMakefile each time you run make, and that's a
pain).

Fixes various problems with getting the scripts right on Windows.
Binaries are universally executable by /bin/sh, cmd.exe and rawSystem,
so this allows us to remove some platform-specific hacks.

1. Record disambiguation (-fdisambiguate-record-fields)

In record construction and pattern matching (although not
in record updates) it is clear which field name is intended
even if there are several in scope.  This extension uses
the constructor to disambiguate.  Thus
	C { x=3 }
uses the 'x' field from constructor C (assuming there is one)
even if there are many x's in scope.


2. Record punning (-frecord-puns)

In a record construction or pattern match or update you can 
omit the "=" part, thus
	C { x, y }
This is just syntactic sugar for
	C { x=x, y=y }


3.  Dot-dot notation for records (-frecord-dot-dot)

In record construction or pattern match (but not update) 
you can use ".." to mean "all the remaining fields".  So

	C { x=v, .. }

means to fill in the remaining fields to give

	C { x=v, y=y }

(assuming C has fields x and y).  This might reasonably
considered very dodgy stuff.  For pattern-matching it brings
into scope a bunch of things that are not explictly mentioned;
and in record construction it just picks whatver 'y' is in
scope for the 'y' field.   Still, Lennart Augustsson really
wants it, and it's a feature that is extremely easy to explain.


Implementation
~~~~~~~~~~~~~~
I thought of using the "parent" field in the GlobalRdrEnv, but
that's really used for import/export and just isn't right for this.
For example, for import/export a field is a subordinate of the *type
constructor* whereas here we need to know what fields belong to a
particular *data* constructor.

The main thing is that we need to map a data constructor to its
fields, and we need to do so in the renamer.   For imported modules
it's easy: just look in the imported TypeEnv.  For the module being
compiled, we make a new field tcg_field_env in the TcGblEnv.
The important functions are
	RnEnv.lookupRecordBndr
	RnEnv.lookupConstructorFields

There is still a significant infelicity in the way the renamer
works on patterns, which I'll tackle next.


I also did quite a bit of refactoring in the representation of
record fields (mainly in HsPat).***END OF DESCRIPTION***

Place the long patch description above the ***END OF DESCRIPTION*** marker.
The first line of this file will be the patch name.


This patch contains the following changes:

M ./compiler/deSugar/Check.lhs -3 +5
M ./compiler/deSugar/Coverage.lhs -6 +7
M ./compiler/deSugar/DsExpr.lhs -6 +13
M ./compiler/deSugar/DsMeta.hs -8 +8
M ./compiler/deSugar/DsUtils.lhs -1 +1
M ./compiler/deSugar/MatchCon.lhs -2 +2
M ./compiler/hsSyn/Convert.lhs -3 +3
M ./compiler/hsSyn/HsDecls.lhs -9 +25
M ./compiler/hsSyn/HsExpr.lhs -13 +3
M ./compiler/hsSyn/HsPat.lhs -25 +63
M ./compiler/hsSyn/HsUtils.lhs -3 +3
M ./compiler/main/DynFlags.hs +6
M ./compiler/parser/Parser.y.pp -13 +17
M ./compiler/parser/RdrHsSyn.lhs -16 +18
M ./compiler/rename/RnBinds.lhs -2 +2
M ./compiler/rename/RnEnv.lhs -22 +82
M ./compiler/rename/RnExpr.lhs -34 +12
M ./compiler/rename/RnHsSyn.lhs -3 +2
M ./compiler/rename/RnSource.lhs -50 +78
M ./compiler/rename/RnTypes.lhs -50 +84
M ./compiler/typecheck/TcExpr.lhs -18 +18
M ./compiler/typecheck/TcHsSyn.lhs -20 +21
M ./compiler/typecheck/TcPat.lhs -8 +6
M ./compiler/typecheck/TcRnMonad.lhs -6 +15
M ./compiler/typecheck/TcRnTypes.lhs -2 +11
M ./compiler/typecheck/TcTyClsDecls.lhs -3 +4
M ./docs/users_guide/flags.xml +7
M ./docs/users_guide/glasgow_exts.xml +42

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).