GitLab

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.

For the most part, this patch simply renames functions which had been used
for closure conversion and hence have CC in their name. It also changes the
OccNames generated by vectorisation.

- Thanks to Roman for spotting the problem.

We should sort rules and instances lexicographically, not by Unique,
in interface files, else we get unnecessary "rules changed" and hence
unnecessary recompilation.

This bug has been there since the interface-file upheaval that put Names
into IfaceSyn.

Associated types in import lists require special care and the new name
parent code broke that.  What's the problem?  in the presence of ATs
the name parent relation can have a depth of two (not just one as in H98).
Here is an example:

  class GMapKey a where
    data GMap a :: * -> *
  instance GMapKey Int where
    data GMap Int v = GMapInt ...

The data constructor GMapInt's parent is GMap whose parent in turn is the 
class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types 
have no parents (which is in some places in the code represented by making 
them their own parent).

I fixed this by extending the information in filterImport's occ_env and
taking the case of associated types explicitly in consideration when 
processing the various forms of IE items.

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

Avoid possibility of name clash

Mon Sep 18 19:48:00 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Fix category of representation tycon
  Mon Sep 11 16:18:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Fix category of representation tycon

Mon Sep 18 19:40:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Get of fam inst index in ifaces
  Fri Sep  8 16:31:26 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Get of fam inst index in ifaces
    - Removes the explicit index to get unique names for derived tycons for family
      instances again, following a suggestion by SPJ.
    - We now derive the coercion tycon name from the name of the representation 
      tycon, which is in the iface anyways.
    
    *** WARNING: Change of interface file format! ***
    ***          Recompile from scratch!          ***

Mon Sep 18 19:35:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Straightened out implicit coercions for indexed types
  Mon Sep  4 23:46:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Straightened out implicit coercions for indexed types
    - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now
      include the coercion of indexed data/newtypes.
    - Name generation for the internal names of indexed data/newtypes now uses
      the same counter that generates the dfun unique indexes (ie, class and type
      instances are counted with the one counter).  We could make this two 
      separate counters if that's what's preferred.
    - The unique index of a data/newtype instances needs to go into the iface, so
      that we can generate the same names on slurping in the iface as when the
      original module was generated.  This is a bit yucky, but I don't see a way
      to avoid that (other than putting the full blown internal tycon name and 
      coercion name into the iface, which IMHO would be worse).
    - The predicate for when a datacon has a wrapper didn't take GADT
      equations nor whether it comes froma  family instance into account.
    
    *** WARNING!  This patch changed the interface file format. ***
    ***           Please recompile from scratch.                ***

Mon Sep 18 19:11:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Pattern matching of indexed data types
  Thu Aug 24 14:17:44 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Pattern matching of indexed data types
    - This patch is the last major puzzle piece to type check and desugar indexed 
      data types (both toplevel and associated with a class).
    - However, it needs more testing - esp wrt to accumlating CoPats - and some 
      static sanity checks for data instance declarations are still missing.
    - There are now two detailed notes in MkIds and TcPat on how the worker/wrapper
      and coercion story for indexed data types works.

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!        **

Fri Aug  4 15:11:01 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Massive patch for the first months work adding System FC to GHC #1
  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.

Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.

The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level.  The build system now makes no
pretense at being multi-project, it is just the GHC build system.

No doubt this will break many things, and there will be a period of
instability while we fix the dependencies.  A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.

Check for constructors in type signatures

Add support for UTF-8 source files

GHC finally has support for full Unicode in source files.  Source
files are now assumed to be UTF-8 encoded, and the full range of
Unicode characters can be used, with classifications recognised using
the implementation from Data.Char.  This incedentally means that only
the stage2 compiler will recognise Unicode in source files, because I
was too lazy to port the unicode classifier code into libcompat.

Additionally, the following synonyms for keywords are now recognised:

  forall symbol 	(U+2200)	forall
  right arrow   	(U+2192)	->
  left arrow   		(U+2190)	<-
  horizontal ellipsis 	(U+22EF)	..

there are probably more things we could add here.

This will break some source files if Latin-1 characters are being used.
In most cases this should result in a UTF-8 decoding error.  Later on
if we want to support more encodings (perhaps with a pragma to specify
the encoding), I plan to do it by recoding into UTF-8 before parsing.

Internally, there were some pretty big changes:

  - FastStrings are now stored in UTF-8

  - Z-encoding has been moved right to the back end.  Previously we
    used to Z-encode every identifier on the way in for simplicity,
    and only decode when we needed to show something to the user.
    Instead, we now keep every string in its UTF-8 encoding, and
    Z-encode right before printing it out.  To avoid Z-encoding the
    same string multiple times, the Z-encoding is cached inside the
    FastString the first time it is requested.

    This speeds up the compiler - I've measured some definite
    improvement in parsing at least, and I expect compilations overall
    to be faster too.  It also cleans up a lot of cruft from the
    OccName interface.  Z-encoding is nicely hidden inside the
    Outputable instance for Names & OccNames now.

  - StringBuffers are UTF-8 too, and are now represented as
    ForeignPtrs.

  - I've put together some test cases, not by any means exhaustive,
    but there are some interesting UTF-8 decoding error cases that
    aren't obvious.  Also, take a look at unicode001.hs for a demo.

-----------------------------------------
	Fix 'mkName' operator in Template Haskell
	so that it handles built-in syntax
	-----------------------------------------

	Merge to stable branch

The 'mkName' function in Template Haskell wasn't dealing correctly with
built-in syntax.  The parser generates Exact RdrNames for built-in syntax
operators, such as ':' and '[]'; and hence so should Convert.

At the same time I'm now generating a better error message in TH when
you use a constructor as a variable or vice versa.

Better TH -> HsSyn conversion

	Merge to stable (attempt)

This commit monad-ises the TH syntax -> HS syntax conversion.
This means that error messages can be reported in a more civilised
way.  It also ensures that the entire structure is converted eagerly.
That means that any exceptions buried inside it are triggered 
during conversion, and caught by the exception handler in TcSplice.
Before, they could be triggered later, and looked like comiler
crashes.

refactoring (use record fields instead of selector functions)

From: Autrijus Tang <autrijus@autrijus.org>

This big commit does several things at once (aeroplane hacking)
which change the format of interface files.  

	So you'll need to recompile your libraries!

1. The "stupid theta" of a newtype declaration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Retain the "stupid theta" in a newtype declaration.
For some reason this was being discarded, and putting it
back in meant changing TyCon and IfaceSyn slightly.
   

2. Overlap flags travel with the instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arrange that the ability to support overlap and incoherence
is a property of the *instance declaration* rather than the
module that imports the instance decl.  This allows a library
writer to define overlapping instance decls without the
library client having to know.  

The implementation is that in an Instance we store the
overlap flag, and preseve that across interface files


3. Nuke the "instnce pool" and "rule pool"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A major tidy-up and simplification of the way that instances
and rules are sucked in from interface files.  Up till now
an instance decl has been held in a "pool" until its "gates" 
(a set of Names) are in play, when the instance is typechecked
and added to the InstEnv in the ExternalPackageState.  
This is complicated and error-prone; it's easy to suck in 
too few (and miss an instance) or too many (and thereby be
forced to suck in its type constructors, etc).

Now, as we load an instance from an interface files, we 
put it straight in the InstEnv... but the Instance we put in
the InstEnv has some Names (the "rough-match" names) that 
can be used on lookup to say "this Instance can't match".
The detailed dfun is only read lazily, and the rough-match
thing meansn it is'nt poked on until it has a chance of
being needed.

This simply continues the successful idea for Ids, whereby
they are loaded straightaway into the TypeEnv, but their
TyThing is a lazy thunk, not poked on until the thing is looked
up.

Just the same idea applies to Rules.

On the way, I made CoreRule and Instance into full-blown records
with lots of info, with the same kind of key status as TyCon or 
DataCon or Class.  And got rid of IdCoreRule altogether.   
It's all much more solid and uniform, but it meant touching
a *lot* of modules.


4. Allow instance decls in hs-boot files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allowing instance decls in hs-boot files is jolly useful, becuase
in a big mutually-recursive bunch of data types, you want to give
the instances with the data type declarations.  To achieve this

* The hs-boot file makes a provisional name for the dict-fun, something
  like $fx9.

* When checking the "mother module", we check that the instance
  declarations line up (by type) and generate bindings for the 
  boot dfuns, such as
	$fx9 = $f2
  where $f2 is the dfun generated by the mother module

* In doing this I decided that it's cleaner to have DFunIds get their
  final External Name at birth.  To do that they need a stable OccName,
  so I have an integer-valued dfun-name-supply in the TcM monad.
  That keeps it simple.

This feature is hardly tested yet.


5. Tidy up tidying, and Iface file generation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main/TidyPgm now has two entry points:

  simpleTidyPgm is for hi-boot files, when typechecking only
  (not yet implemented), and potentially when compiling without -O.
  It ignores the bindings, and generates a nice small TypeEnv.

  optTidyPgm is the normal case: compiling with -O.  It generates a
  TypeEnv rich in IdInfo

MkIface.mkIface now only generates a ModIface.  A separate
procedure, MkIface.writeIfaceFile, writes the file out to disk.

Final wibbles, I hope

decode OccNames in dumpStyle too

The type variables in the types of wired-in entities were built using
mkVarOcc, which gives a variable name rather than a type variable
name.  Normally the compiler doesn't care, but when tidying types for
output to the user the tidier would consider a VarName as distinct
from a TvName, and not give them different print names.

This fix makes puts all the type variables in the TvName namespace.

---------------------------------------------
Type signatures are no longer instantiated with skolem constants
	---------------------------------------------

	Merge to STABLE

Consider

  p :: a
  q :: b
  (p,q,r) = (r,r,p)

Here, 'a' and 'b' end up being the same, because they are both bound
to the type for 'r', which is just a meta type variable.  So 'a' and 'b'
can't be skolems.

Sigh.  This commit goes back to an earlier way of doing things, by
arranging that type signatures get instantiated with *meta* type
variables; then at the end we must check that they have not been
unified with types, nor with each other.

This is a real bore.  I had to do quite a bit of related fiddling around
to make error messages come out right.  Improved one or two.

Also a small unrelated fix to make
	:i (:+)
print with parens in ghci.  Sorry this got mixed up in the same commit.

Fix bug in decode_tuple (fixes tc177(prof))

Make error messages consistent

-----------------------------
        Improve deprecation reporting
	-----------------------------

	[PS: the 1.31 commit of basicTypes/RdrName.lhs
	 also belongs in this commit.]

Up to now, deprecated functions are only reported when imported
from the module defining them, but not when re-exporting.  This
seems wrong -- often a "root" module gathers exports from sub-modules.

It turned out that there was a structural problem: the deprectaions
were getting put in the GlobalRdrEnv, and it simply doesn't have
the defining-module's interface to hand.

So this commit removes gre_deprec from GRE, and moves deprecation
reporting from the individual occurrences (RnEnv.lookupGreRn) to
RnNames.reportUnusedNames.  In many ways this is a better place for it,
because there we get a global view of the entire module.  For example,
repeated use of a single deprecated thing will only give rise to one
warning instead of multiple warnings.

So here's what we now get:

  Foo.hs:3:0:
    Warning: Deprecated use of Variable `withObject'
	     (imported from Foreign.Marshal, but defined in Foreign.Marshal.Utils)
	     use `with' instead

------------------------------------
	Major increment for Template Haskell
	------------------------------------

1.  New abstract data type "Name" which appears where String used to be.
    E.g. 	data Exp = VarE Name | ...

2.  New syntax 'x and ''T, for quoting Names.  It's rather like [| x |]
    and [t| T |] respectively, except that

	a) it's non-monadic:  'x :: Name
	b) you get a Name not an Exp or Type

3.  reify is an ordinary function
	reify :: Name -> Q Info
    New data type Info which tells what TH knows about Name

4.  Local variables work properly.  So this works now (crashed before):
	f x = $( [| x |] )

5.  THSyntax is split up into three modules:

  Language.Haskell.TH		TH "clients" import this

  Language.Haskell.TH.THSyntax	data type declarations and internal stuff

  Language.Haskell.TH.THLib	Support library code (all re-exported
				by TH), including smart constructors and
				pretty printer

6.  Error reporting and recovery are in (not yet well tested)

	report :: Bool {- True <=> fatal -} -> String -> Q ()
	recover :: Q a -> Q a -> Q a

7.  Can find current module

	currentModule :: Q String


Much other cleaning up, needless to say.