GitLab

Don't print the "compilation IS NOT required" in quiet mode (-v0).

field: robustify - give a parse error (rather than p-match failure)
if LHS isn't known.

Wibble in eqString

Fix spurious sp increment in RET_{VEC_}_SMALL printing code.

MERGE TO STABLE

Dont try to float unboxed things to top level

Add a FAQ entry about using getContents in GHCi.

ILX ifdefery

Various updates to track the state of GHC and ILX.

Track reality a bit.

Implement -keep-il-file.

Implement -keep-il-file

Add -keep-il-file.

PrelGHC.dll -> PrelGHC.i_o, and a few other corrections to follow
changes to ILX.

Reflect reality ever-so-slightly better.

Remove unused import.

Removed unused imports.

Get rid of \rs at the end of lines in prescripts and postscripts to
work around Windows dodginess.

Export run_queue_hd to the dynamic linker; TkHaskell has a grotesque
hack which requires it.

Allow default RTS options to be specified by linking in an object file
which defines the symbol `ghc_rts_opts' to point to a string of RTS
options.

This is preferred to using defaultsHook(), if possible.  Perhaps we
could remove defaultsHook().

(won't work with DLL's; if we ever ressurrect them we'll
have to deal with this somehow).

Actually bomb out with an error message if the maximum heap size is
smaller than the minimum allocation area size.

Fix a bug in the heap size calculation, where a negative result wasn't
noticed because we're working with unsigned types.  We now explicitly
test that the heap has enough room for the minimum allocation area
size, otherwise a heap overflow is reported.

---------------------------
	Match rules before inlining
	---------------------------

This commit fulfils a long-standing wish by Manuel that RULES
matching occurs before inlining.  So if a RULE matches, it'll
get used, even if the function can also be inlined.

It's a bit dodgy to actually rely on this, because maybe the rule
doesn't match *yet* but will do after a bit more transformation.
But it does help with things like class operations.  Class ops are
simply selectors which pick a method out of a dictionary, so they
are inlined rather vigorously.  But we might want a RULE for a
class method (e.g. (==) [Char] = eqString), and such rules would
practically never fire if inlining took priority.

Stuff to make a RULE work for
	eqString "foo" "foo" = True
(etc.)  The rule is of course a BuiltinRule in PrelRules

Add a rule for equality on strings

Fix a long-standing lossage of rules attached to class operations
(A one-line fix to SimplCore.updateBinders.)

Rename 'doDiscard' to 'lexPragma', and make it EOF-resistant.
As was, it would run off the end of a StringBuffer (and SIGSEGV,
most likely) if a pragma wasn't properly closed.

Provide finer-grained control for turning off mk/target.mk's
'all', 'boot' and 'install' rules. i.e., instead of having
the variable NO_ALL_TARGETS control the defnition of rules
for all three, NO_ALL_TARGET, NO_BOOT_TARGET, and NO_INSTALL_TARGET
lets you individually control which ones you don't want.

Sub-projects (GC and HDirect, for example) have the need
to turn off the 'boot' rule, which is what motivated this
change.

Tweaks to the 5.02 InstallShield to improve presentation and the range of
help files available.

Inline BasicTypes.CompilerPhase tysyn to workaround
Outputable <--> BasicTypes module loop.

Add note that it's possible to move the Windows GHC tree around if you want
to (e.g. to get it on a path without spaces).

Wibble

Specialise reduce

------------------
		Simon's big commit
		------------------
	[ These files seem to have been left out for some reason ]


This commit, which I don't think I can sensibly do piecemeal, consists
of the things I've been doing recently, mainly directed at making
Manuel, George, and Marcin happier with RULES.


Reogranise the simplifier
~~~~~~~~~~~~~~~~~~~~~~~~~
1. The simplifier's environment is now an explicit parameter.  This
makes it a bit easier to figure out where it is going.

2. Constructor arguments can now be arbitrary expressions, except
when the application is the RHS of a let(rec).  This makes it much
easier to match rules like

	RULES
	    "foo"  f (h x, g y) = f' x y

In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
constructor application where necessary.  In the occurrence analyser,
there's a new piece of context info (OccEncl) to say whether a
constructor app is in a place where it should be in ANF.  (Unless
it knows this it'll give occurrence info which will inline the
argument back into the constructor app.)

3. I'm experimenting with doing the "float-past big lambda" transformation
in the full laziness pass, rather than mixed in with the simplifier (was
tryRhsTyLam).

4.  Arrange that
	case (coerce (S,T) (x,y)) of ...
will simplify.  Previous it didn't.
A local change to CoreUtils.exprIsConApp_maybe.

5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
error function in one branch.


Phase numbers, RULES, and INLINE pragmas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.  Phase numbers decrease from N towards zero (instead of increasing).
This makes it easier to add new earlier phases, which is what users want
to do.

2.  RULES get their own phase number, N, and are disabled in phases before N.

e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}

Note the [2], which says "only active in phase 2 and later".

3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
in just the same way as the phase number on RULE; that is, the Id is not inlined
in phases earlier than N.  In phase N and later the Id *may* be inlined, and
here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
as soon as it *may* be inlined it probably *will* be inlined.

The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
like the RULES case (i.e. in square brackets).  This should also make sure
you examine all such phase numbers; many will need to change now the numbering
is reversed.

Inlining Ids is no longer affected at all by whether the Id appears on the
LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
pragma to stop it being inlined too early.


Implementation notes:

*  A new data type, BasicTypes.Activation says when a rule or inline pragma
is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
obvious thing (all in BasicTypes).

* Slight change in the SimplifierSwitch data type, which led to a lot of
simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.

* The InlinePragma in the IdInfo of an Id is now simply an Activation saying
when the Id can be inlined.  (It used to be a rather bizarre pair of a
Bool and a (Maybe Phase), so this is much much easier to understand.)

* The simplifier has a "mode" environment switch, replacing the old
black list.  Unfortunately the data type decl has to be in
CmdLineOpts, because it's an argument to the CoreDoSimplify switch

    data SimplifierMode = SimplGently | SimplPhase Int

Here "gently" means "no rules, no inlining".   All the crucial
inlining decisions are now collected together in SimplMonad
(preInlineUnconditionally, postInlineUnconditionally, activeInline,
activeRule).


Specialisation
~~~~~~~~~~~~~~
1.  Only dictionary *functions* are made INLINE, not dictionaries that
have no parameters.  (This inline-dictionary-function thing is Marcin's
idea and I'm still not sure whether it's a good idea.  But it's definitely
a Bad Idea when there are no arguments.)

2.  Be prepared to specialise an INLINE function: an easy fix in
Specialise.lhs

But there is still a problem, which is that the INLINE wins
at the call site, so we don't use the specialised version anyway.
I'm still unsure whether it makes sense to SPECIALISE something
you want to INLINE.





Random smaller things
~~~~~~~~~~~~~~~~~~~~~~

* builtinRules (there was only one, but may be more) in PrelRules are now
  incorporated.   They were being ignored before...

* OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL

* Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
  forgotten exactly what!

------------------
		Simon's big commit
		------------------

This commit, which I don't think I can sensibly do piecemeal, consists
of the things I've been doing recently, mainly directed at making
Manuel, George, and Marcin happier with RULES.


Reogranise the simplifier
~~~~~~~~~~~~~~~~~~~~~~~~~
1. The simplifier's environment is now an explicit parameter.  This
makes it a bit easier to figure out where it is going.

2. Constructor arguments can now be arbitrary expressions, except
when the application is the RHS of a let(rec).  This makes it much
easier to match rules like

	RULES
	    "foo"  f (h x, g y) = f' x y

In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
constructor application where necessary.  In the occurrence analyser,
there's a new piece of context info (OccEncl) to say whether a
constructor app is in a place where it should be in ANF.  (Unless
it knows this it'll give occurrence info which will inline the
argument back into the constructor app.)

3. I'm experimenting with doing the "float-past big lambda" transformation
in the full laziness pass, rather than mixed in with the simplifier (was
tryRhsTyLam).

4.  Arrange that
	case (coerce (S,T) (x,y)) of ...
will simplify.  Previous it didn't.
A local change to CoreUtils.exprIsConApp_maybe.

5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
error function in one branch.


Phase numbers, RULES, and INLINE pragmas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1.  Phase numbers decrease from N towards zero (instead of increasing).
This makes it easier to add new earlier phases, which is what users want
to do.

2.  RULES get their own phase number, N, and are disabled in phases before N.

e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}

Note the [2], which says "only active in phase 2 and later".

3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
in just the same way as the phase number on RULE; that is, the Id is not inlined
in phases earlier than N.  In phase N and later the Id *may* be inlined, and
here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
as soon as it *may* be inlined it probably *will* be inlined.

The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
like the RULES case (i.e. in square brackets).  This should also make sure
you examine all such phase numbers; many will need to change now the numbering
is reversed.

Inlining Ids is no longer affected at all by whether the Id appears on the
LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
pragma to stop it being inlined too early.


Implementation notes:

*  A new data type, BasicTypes.Activation says when a rule or inline pragma
is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
obvious thing (all in BasicTypes).

* Slight change in the SimplifierSwitch data type, which led to a lot of
simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.

* The InlinePragma in the IdInfo of an Id is now simply an Activation saying
when the Id can be inlined.  (It used to be a rather bizarre pair of a
Bool and a (Maybe Phase), so this is much much easier to understand.)

* The simplifier has a "mode" environment switch, replacing the old
black list.  Unfortunately the data type decl has to be in
CmdLineOpts, because it's an argument to the CoreDoSimplify switch

    data SimplifierMode = SimplGently | SimplPhase Int

Here "gently" means "no rules, no inlining".   All the crucial
inlining decisions are now collected together in SimplMonad
(preInlineUnconditionally, postInlineUnconditionally, activeInline,
activeRule).


Specialisation
~~~~~~~~~~~~~~
1.  Only dictionary *functions* are made INLINE, not dictionaries that
have no parameters.  (This inline-dictionary-function thing is Marcin's
idea and I'm still not sure whether it's a good idea.  But it's definitely
a Bad Idea when there are no arguments.)

2.  Be prepared to specialise an INLINE function: an easy fix in
Specialise.lhs

But there is still a problem, which is that the INLINE wins
at the call site, so we don't use the specialised version anyway.
I'm still unsure whether it makes sense to SPECIALISE something
you want to INLINE.





Random smaller things
~~~~~~~~~~~~~~~~~~~~~~

* builtinRules (there was only one, but may be more) in PrelRules are now
  incorporated.   They were being ignored before...

* OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL

* Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
  forgotten exactly what!

-------------------------------
	Code generation and SRT hygiene
	-------------------------------

This is a big tidy up commit.  I don't think it breaks anything,
but it certainly makes the code clearer (to me).

I'm not certain that you can use it without sucking in my other
big commit... they come from the same tree.


Core-to-STG, live variables and Static Reference Tables (SRTs)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I did a big tidy-up of the live-variable computation in CoreToStg.
The key idea is that the live variables consist of two parts:
	dynamic live vars
	static live vars (CAFs)

These two always travel round together, but they were always
treated separately by the code until now. Now it's a new data type:

type LiveInfo = (StgLiveVars, 	-- Dynamic live variables;
				-- i.e. ones with a nested (non-top-level) binding
		 CafSet)	-- Static live variables;
				-- i.e. top-level variables that are CAFs or refer to them

There's lots of documentation in CoreToStg.

Code generation
~~~~~~~~~~~~~~~
Arising from this, I found that SRT labels were stored in
a LambdaFormInfo during code generation, whereas they *ought*
to be in the ClosureInfo (which in turn contains a LambdaFormInfo).

This led to lots of changes in ClosureInfo, and I took the opportunity
to make it into a labelled record.

Similarly, I made the data type in AbstractC a bit more explicit:

  -- C_SRT is what StgSyn.SRT gets translated to...
  -- we add a label for the table, and expect only the 'offset/length' form

data C_SRT = NoC_SRT
	   | C_SRT CLabel !Int{-offset-} !Int{-length-}

(Previously there were bottoms lying around.)

- split documentation off into a separate package
- adapt to new docbook setup in RH7.1

Make the print stylesheet generate a TOC for sets (so the PDF manual
has a front TOC indicating that it contains both the user's guide and
libraries guide).

A simple question with a simple answer; how refreshing.

ENODEV should really be an UnsupportedOperation, not NoSuchThing.

A failure while trying to set O_NONBLOCK on a file descriptor should
be a non-fatal error.  It turns out that on FreeBSD it is an error
(ENODEV) to try to set O_NONBLOCK on /dev/null.

MERGE TO STABLE

Let's try that last commit again, and get it right this time...