GitLab

instead of something like "ghc-6.8.2: ...", which causes problems in
the test suite.  In any case, "<command line>" seems a more
appropriate context for these errors, the only question is whether
we're using CmdLineError incorrectly anywhere.

Another idea suggested by Roman, happily involving a one-line change.  Here's 
the new Note in Specialise:

Note [Auto-specialisation and RULES]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider:
   g :: Num a => a -> a
   g = ...

   f :: (Int -> Int) -> Int
   f w = ...
   {-# RULE f g = 0 #-}

Suppose that auto-specialisation makes a specialised version of
g::Int->Int That version won't appear in the LHS of the RULE for f.
So if the specialisation rule fires too early, the rule for f may
never fire.

It might be possible to add new rules, to "complete" the rewrite system.
Thus when adding
	RULE forall d. g Int d = g_spec
also add
	RULE f g_spec = 0

But that's a bit complicated.  For now we ask the programmer's help,
by *copying the INLINE activation pragma* to the auto-specialised rule.
So if g says {-# NOINLINE[2] g #-}, then the auto-spec rule will also
not be active until phase 2. 

Remove the now-redundant "const-dicts" field in SpecPrag

In dsBinds, abstract over constant dictionaries in the RULE.
This avoids the creation of a redundant, duplicate, rule later
in the Specialise pass, which was happening before.

There should be no effect on performance either way, just less
duplicated code, and the compiler gets a little simpler.

6.6 behaviour:
  - ./.ghci
  - $HOME/.ghci

6.8.[12] behaviour:
  - ./.ghci
  - Windows: c:/Documents and Settings/<user>/.ghci
  - Unix: $HOME/.ghci

6.10 (and 6.8.3 when this is merged):
  - ./.ghci
  - Windows: c:/Documents and Settings/<user>/Application Data/ghc/ghci.conf
  - Unix: $HOME/.ghc/ghci.conf
  - $HOME/.ghci

We will need to document this in the 6.8.3 release notes because it
may affect Windows users who have adapted their setup to 6.8.[12].

Also put the :help docs back within 80 columns

   - #1839 asks for a ghc-pkg dump feature, #1463 for the ability
     to query the same fields in several packages at once.

   - this patch enables substring matching for packages in 'list',
     'describe', and 'field', and for modules in find-module. it
     also allows for comma-separated multiple fields in 'field'.
     substring matching can optionally ignore cases to avoid the
     rather unpredictable capitalisation of packages.

   - the patch is not quite as full-featured as the one attached
     to #1839, but avoids the additional dependency on regexps.
     open ended substrings are indicated by '*' (only the three
     forms prefix*, *suffix, *infix* are supported)

   - on windows, the use of '*' for package/module name globbing
     leads to conflicts with filename globbing: by default, windows
     programs are self-globbing, and bash adds another level of
     globbing on top of that. it seems impossible to escape '*'
     from both levels of globbing, so we disable default globbing
     for ghc-pkg and ghc-pkg-inplace. users of bash will still
     have filename globbing available, users of cmd won't.

   - if it is considered necessary to reenable filename globbing
     for cmd users, it should be done selectively, only for
     filename parameters. to this end, the patch includes a
     glob.hs program which simply echoes its parameters after
     filename globbing. see the commented out glob command in
     Main.hs for usage or testing.

   - this covers both tickets, and permits for the most common
     query patterns (finding all packages contributing to the
     System. hierarchy, finding all regex or string packages,
     listing all package maintainers or haddock directories,
     ..), which not only i have wanted to have for a long time.

     examples (the quotes are needed to escape shell-based
     filename globbing and should be omitted in cmd.exe):

       ghc-pkg list '*regex*' --ignore-case
       ghc-pkg list '*string*' --ignore-case
       ghc-pkg list '*gl*' --ignore-case
       ghc-pkg find-module 'Data.*'
       ghc-pkg find-module '*Monad*'
       ghc-pkg field '*' name,maintainer
       ghc-pkg field '*' haddock-html
       ghc-pkg describe '*'

The previous attempt to fix this (#1873, #1360) left a problem that
occurred when the first :load of the program failed (#2049).  

Now I've implemented a different strategy: between :loads, we remember
all the :module commands, and just replay them after a :reload.  This
is in addition to remembering all the package modules added with
:module, which is orthogonal.

This approach is simpler than the previous one, and seems to do the
right thing in all the cases I could think of.  Let's hope this is the
last bug in this series...

 - remove $(ghc_ge_601), $(ghc_ge_602), $(ghc_ge_603)
 - configure now checks the GHC version number
 - there are probably various cleanups that we can now do in compat/
   and compiler/, but I haven't done those yet.

This patch stops the worker/wrapper transform working on an INLINE thing,
even if it's in a recursive group.  It might not be the loop breaker.  Indeed
a recursive group might have no loop breaker, if the only recursion is 
through rules.

Again, this change was provoked by one of Roman's NDP libraries.
Specifically the Rec { splitD, splitJoinD } group in 
	Data.Array.Parallel.Unlifted.Distributed.Arrays

Simon

This is another gloss on the now-quite-subtle and heavily-documented algorithm
for choosing loop breakers.

This fix, provoked by Roman's NDP library, makes sure that when we are choosing
a loop breaker we only take into account variables free on the *rhs* of a rule
not the *lhs*.

Most of the new lines are comments!

Sorry, this was my fault, a consequence of the quasi-quoting patch.  

I've added rn062 as a test.

When running with ghc -e, exceptions should claim to be from the program
that we are running, not ghc.