GitLab

o Moved BlockId stuff to a new file to avoid module recursion
o Defined stack areas for parameter-passing locations and spill slots
o Part way through replacing copy in and copy out nodes
  - added movement instructions for stack pointer
  - added movement instructions for call and return parameters
    (but not with the proper calling conventions)
o Inserting spills and reloads for proc points is now procpoint-aware
  (it was relying on the presence of a CopyIn node as a proxy for
   procpoint knowledge)
o Changed ZipDataflow to expect AGraphs (instead of being polymorphic in
   the type of graph)

This is a much more robust way to do recompilation checking.  The idea
is to create a fingerprint of the ABI of an interface, and track
dependencies by recording the fingerprints of ABIs that a module
depends on.  If any of those ABIs have changed, then we need to
recompile.

In bug #1372 we weren't recording dependencies on package modules,
this patch fixes that by recording fingerprints of package modules
that we depend on.  Within a package there is still fine-grained
recompilation avoidance as before.

We currently use MD5 for fingerprints, being a good compromise between
efficiency and security.  We're not worried about attackers, but we
are worried about accidental collisions.

All the MD5 sums do make interface files a bit bigger, but compile
times on the whole are about the same as before.  Recompilation
avoidance should be a bit more accurate than in 6.8.2 due to fixing
#1959, especially when using -O.

The "magic number mismatch: old/corrupt interface file?" error now tells
us what we got, and what we expected.

Very little parameter passing is needed without it, so there was no real
benefit to it.

This patch implements three new features:
* view patterns (syntax: expression -> pat in a pattern)
* working versions of record wildcards and record puns
See the manual for detailed descriptions.

Other minor observable changes:
* There is a check prohibiting local fixity declarations
  when the variable being fixed is not defined in the same let
* The warn-unused-binds option now reports warnings for do and mdo stmts

Implementation notes: 

* The pattern renamer is now in its own module, RnPat, and the
implementation is now in a CPS style so that the correct context is
delivered to pattern expressions.

* These features required a fairly major upheaval to the renamer.
Whereas the old version used to collect up all the bindings from a let
(or top-level, or recursive do statement, ...) and put them into scope
before renaming anything, the new version does the collection as it
renames.  This allows us to do the right thing with record wildcard
patterns (which need to be expanded to see what names should be
collected), and it allows us to implement the desired semantics for view
patterns in lets.  This change had a bunch of domino effects brought on
by fiddling with the top-level renaming.

* Prior to this patch, there was a tricky bug in mkRecordSelId in HEAD,
which did not maintain the invariant necessary for loadDecl.  See note
[Tricky iface loop] for details.

Fixes building with -Werror (i.e. validate) and GHC < 6.6

Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.

Now, if a single module *anywhere* on the module tree is built with
-fhpc, the binary will enable reading/writing of <bin>.tix.

Previously, you needed to compile Main to allow coverage to operate.

This changes the file format for .hi files; you will need to recompile every library.

mapAccumL and mapAccumR are in Data.List now.
mapAccumB is unused.

  ** This patch changes the interface file format.  All libraries etc **
  ** need to be compiled from scratch.                                **

- This patch removes "newtype family" declarations.
- "newtype instance" declarations can now be instances of data families
- This also fixes bug #1331

  ** This patch changes the interface format.  All libraries and all of **
  ** Stage 2 & 3 need to be re-compiled from scratch.                   **

This has been a long-standing ToDo.

	WARNING: this patch changes interface-file formats slightly
	 	 you will need to recompile your libraries

Duncan Coutts wanted to export a function that has a NOINLNE pragma
in a local let-defintion.  This works fine within a module, but was 
not surviving across the interface-file serialisation.

http://www.haskell.org/pipermail/glasgow-haskell-users/2007-March/012171.html

Regardless of whether or not he's doing something sensible, it seems
reasonable to try to retain local-binder IdInfo across interface files.
This initial patch just retains inline-pragma info, on the grounds that
other IdInfo can be re-inferred at the inline site.

Interface files get a tiny bit bigger, but it seesm slight.

I broke it during my recent interface-file overhaul

This changes the internal representation of TickBoxes,
from
        Note (TickBox "module" n)  <expr>
into

        case tick<module,n> of
          _ -> <expr>

tick has type :: #State #World, when the module and tick numbe
are stored inside IdInfo.

Binary tick boxes change from

         Note (BinaryTickBox "module" t f) <expr>

into

          btick<module,t,f> <expr>

btick has type :: Bool -> Bool, with the module and tick number
stored inside IdInfo.

This large checkin is the new ghc version of Haskell
Program Coverage, an expression-level coverage tool for Haskell.

Parts:

 - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
 - Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
  - New Note's in Core,
      - TickBox      -- ticked on entry to sub-expression
      - BinaryTickBox  -- ticked on exit to sub-expression, depending
	       	     -- on the boolean result.

  - New Stg level TickBox (no BinaryTickBoxes, though) 

You can run the coverage tool with -fhpc at compile time. 
Main must be compiled with -fhpc. 
				      

- Now each modules carries
  (1) a flag saying whether it contains family instance declarations and
  (2) a list of all modules further down in the import tree that contain
      family instance declarations.
  (The information is split into these two parts for the exact same reasons why
  the info about orphan modules is split, too.)
- This is the first step to *optimised* overlap checking of family instances
  coming from imported modules.

*** WARNING: This patch changes the interface file format! ***
***          Recompile libraries and stage2 from scratch!  ***

This patch is a start on removing import lists and generally tidying
up the top of each module.  In addition to removing import lists:

   - Change DATA.IOREF -> Data.IORef etc.
   - Change List -> Data.List etc.
   - Remove $Id$
   - Update copyrights
   - Re-order imports to put non-GHC imports last
   - Remove some unused and duplicate imports

This large commit combines several interrelated changes:

  - IfaceSyn now contains actual Names rather than the special
    IfaceExtName type.  The binary interface file contains
    a symbol table of Names, where each entry is a (package,
    ModuleName, OccName) triple.  Names in the IfaceSyn point
    to entries in the symbol table.

    This reduces the size of interface files, which should
    hopefully improve performance (not measured yet).

    The toIfaceXXX functions now do not need to pass around
    a function from Name -> IfaceExtName, which makes that
    code simpler.

  - Names now do not point directly to their parents, and the
    nameParent operation has gone away.  It turned out to be hard to
    keep this information consistent in practice, and the parent info
    was only valid in some Names.  Instead we made the following
    changes:

    * ImportAvails contains a new field 
          imp_parent :: NameEnv AvailInfo
      which gives the family info for any Name in scope, and
      is used by the renamer when renaming export lists, amongst
      other things.  This info is thrown away after renaming.

    * The mi_ver_fn field of ModIface now maps to
      (OccName,Version) instead of just Version, where the
      OccName is the parent name.  This mapping is used when
      constructing the usage info for dependent modules.
      There may be entries in mi_ver_fn for things that are not in
      scope, whereas imp_parent only deals with in-scope things.

    * The md_exports field of ModDetails now contains
      [AvailInfo] rather than NameSet.  This gives us
      family info for the exported names of a module.

Also:

   - ifaceDeclSubBinders moved to IfaceSyn (seems like the
     right place for it).

   - heavily refactored renaming of import/export lists.

   - Unfortunately external core is now broken, as it relied on
     IfaceSyn.  It requires some attention.

- Class and type family instances just got a lot more similar.
- FamInst, like Instance, now has a rough match signature.  The idea is the
  same: if the rough match doesn't match, there is no need to pull in the while
  tycon describing the instance (from a lazily read iface).
- IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
  now written into the binary iface (as for class instances), as deriving it
  from the tycon (as before) would render the whole rough matching useless.
- As a result of this, the plumbing of class instances and type instances 
  through the various environments, ModIface, ModGuts, and ModDetails is now
  almost the same.  (The remaining difference are mostly because the dfun of a
  class instance is an Id, but type instance refer to a TyCon, not an Id.)

*** WARNING: The interface file format changed! ***
***	     Rebuild from scratch.		***

Linear implicit parameters have been in GHC quite a while,
but we decided they were a mis-feature and scheduled them for
removal.  This patch does the job.

Mon Sep 18 19:50:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Import/export of data constructors in family instances
  Tue Sep 12 13:54:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Import/export of data constructors in family instances
    - Data constructors of a data/newtype family F can be exported and imported
      by writing F(..) or F(ConName).
    - This appears the most natural from a user's persepctive - although, it has a
      slightly different flavour than similar import/exports items for closed data 
      types.  The data constructors denoted by F(..) vary in dependence on the 
      visible data instances.
    - This has been non-trivial to achieve as RnNames derives its knowledge of what
      sub-binders an F(..) item exports/imports from the relation specified by 
      Name.nameParent - ie, the constructors of a data/newtype instance need to 
      have the family name (not the internal name of the representation tycon) as 
      their parent.
    
    *** WARNING: This patched changes the iface format! ***
    ***          Please re-compile from scratch!	    ***

Mon Sep 18 19:07:30 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Introduce coercions for data instance decls
  Tue Aug 22 20:33:46 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Introduce coercions for data instance decls
    - data instance declarations implicitly generate a coercion moving between the
      representation type and family instance type.
    - The coercion is *implicitly* generated when type checking both source and 
      ifaces.  Ie, we don't safe it in ifaces - this is really exactly as newtype 
      coercions are handled.
    - The previous addition of the instance types to DataCons has been moved to 
      the representation TyCon.  This is more efficient as it is shared between all
      constructors of one representation tycon and it also gathers everything about
      data instances (family tycon, instance types, and coercion) in one place: the
      algTcParent field of TyCon.
    - The coercion is already used in the datacon wrappers, but not yet during type
      checking pattern matching of indexed data types.
    - The code has only been lightly tested, but doesn't seem to break features not
      related to indexed types.  For indexed data types only the pattern matching
      tc code (in TcPat.tcConPat) and some well-formedness checks are still 
      missing.  And there will surely be some bugs to fix.  (newtypes still require
      some more work.)
    
    	   ** WARNING: Interface file format changed! **
    	   **          Recompile from scratch!        **

Mon Sep 18 19:05:18 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Extend TyCons and DataCons to represent data instance decls
  Fri Aug 18 19:11:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Extend TyCons and DataCons to represent data instance decls
    - This is a faily involved patch, but it is not entirely complete:
      + The data con wrapper code for instance data cons needs to apply the
        coercions (which we still have to generate).
      + There are still bugs, but it doesn't seem to affect the compilation of
        code that doesn't use type families.
    
    ** WARNING: Yet another change of the iface format.  **
    **          Recompile everything.                    **

Mon Sep 18 18:58:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Extend Class.Class to include the TyCons of ATs
  Wed Aug 16 16:15:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Extend Class.Class to include the TyCons of ATs

Mon Sep 18 18:50:35 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Extended TyCon and friends to represent family declarations
  Tue Aug 15 16:52:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Extended TyCon and friends to represent family declarations

Fri Aug 11 13:53:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Remove argument variance info of tycons
  - Following SPJ's suggestion, this patch removes the variance information from
    type constructors.  This information was computed, but never used.
  
  ** WARNING: This patch changes the format of interface files **
  **          You will need to rebuild from scratch.           **

Broken up massive patch -=chak
Original log message:  
This is (sadly) all done in one patch to avoid Darcs bugs.
It's not complete work... more FC stuff to come.  A compiler
using just this patch will fail dismally.

This patch pushes through one fundamental change: a module is now
identified by the pair of its package and module name, whereas
previously it was identified by its module name alone.  This means
that now a program can contain multiple modules with the same name, as
long as they belong to different packages.

This is a language change - the Haskell report says nothing about
packages, but it is now necessary to understand packages in order to
understand GHC's module system.  For example, a type T from module M
in package P is different from a type T from module M in package Q.
Previously this wasn't an issue because there could only be a single
module M in the program.

The "module restriction" on combining packages has therefore been
lifted, and a program can contain multiple versions of the same
package.

Note that none of the proposed syntax changes have yet been
implemented, but the architecture is geared towards supporting import
declarations qualified by package name, and that is probably the next
step.

It is now necessary to specify the package name when compiling a
package, using the -package-name flag (which has been un-deprecated).
Fortunately Cabal still uses -package-name.

Certain packages are "wired in".  Currently the wired-in packages are:
base, haskell98, template-haskell and rts, and are always referred to
by these versionless names.  Other packages are referred to with full
package IDs (eg. "network-1.0").  This is because the compiler needs
to refer to entities in the wired-in packages, and we didn't want to
bake the version of these packages into the comiler.  It's conceivable
that someone might want to upgrade the base package independently of
GHC.

Internal changes:

  - There are two module-related types:

        ModuleName      just a FastString, the name of a module
        Module          a pair of a PackageId and ModuleName

    A mapping from ModuleName can be a UniqFM, but a mapping from Module
    must be a FiniteMap (we provide it as ModuleEnv).

  - The "HomeModules" type that was passed around the compiler is now
    gone, replaced in most cases by the current package name which is
    contained in DynFlags.  We can tell whether a Module comes from the
    current package by comparing its package name against the current
    package.

  - While I was here, I changed PrintUnqual to be a little more useful:
    it now returns the ModuleName that the identifier should be qualified
    with according to the current scope, rather than its original
    module.  Also, PrintUnqual tells whether to qualify module names with
    package names (currently unused).

Docs to follow.