GitLab

upd MAX_SPEC_SELECTEE_SIZE comment

Update the out-of-memory error message: the request size isn't known
any more.

warning elimination

A couple of changes related to bug #2 in the previous commit:

 - follow IND_STATICs, now that we can check whether
   we end up in to-space or not

 - improve the commentary

Fix some bugs in compacting GC.

Bug 1: When threading the fields of an AP or PAP, we were grabbing the
info table of the function without unthreading it first.

Bug 2: eval_thunk_selector() might accidentally find itself in
to-space when going through indirections in a compacted generation.
We must check for this case and bale out if necessary.

Bug 3: This is somewhat more nasty.  When we have an AP or PAP that
points to a BCO, the layout info for the AP/PAP is in the BCO's
instruction array, which is two objects deep from the AP/PAP itself.
The trouble is, during compacting GC, we can only safely look one
object deep from the current object, because pointers from objects any
deeper might have been already updated to point to their final
destinations.

The solution is to put the arity and bitmap info for a BCO into the
BCO object itself.  This means BCOs become variable-length, which is a
slight annoyance, but it also means that looking up the arity/bitmap
is quicker.  There is a slight reduction in complexity in the byte
code generator due to not having to stuff the bitmap at the front of
the instruction stream.

#ifdef some more code that belongs to the old strictness analyser.

It turns out we were still compiling the Demand and SaLib modules,
which aren't required unless OLD_STRICTNESS is on (do we still need
OLD_STRICTNESS?).

dsForeigns: common up header files

Friday morning code-wibbling:
- made RetainerProfile.c:firstStack a 'static'
- added RetainerProfile.c:retainerStackBlocks()

drop FILE_SIZE (hasn't been needed by NCG for the past 5 years or so)

reliably clean out mk* binaries

Modifications to the way we calculate CafInfo during tidying (again).

The previous hack of setting the CafInfo on all non-top-level bindings
to NoCafRefs was a hack, and it came back to bite us: when CorePrep
floats out a let to the top level it doesn't create a new binding, and
the existing let binder happens to say NoCafRefs which is unsafe.  It
was caught by an ASSERT in the CoreToStg when compiling the libraries
without -O - compiling without -O tends to result in more
opportunities for CorePrep to float things to the top level.

Now, we calculate CafInfo on the pre-tidied expressions, using the
mapping from Ids to Ids that is being built up during tidying.  This
avoids one loop, but will be slightly slower due to the extra lookups.
However, it means we don't need to set the CafInfo on non-top-level
binders to NoCafRefs.

GNU ar seems to have trouble with duplicate object file names if you
use the 's' modifier, so detect GNU ar here and use a simple 'ar q'
command to create archives.

This bug was tickled when I replaced an 'ar q' with '$(AR)' in
target.mk yesterday: the default $(AR) is 'ar clqs'.

Notes about constructor info tables

replace one instance of ar with $(AR).

Out of memory should be a belch(), not a barf().

Compile libraries with -O

----------------------------------
      Fix a long-standing egregious CorePrep bug
	----------------------------------

	**** Merge to Stable branch ****

CorePrep was eta-reducing

	\x -> (# a,x #)
to
	(#,#) a

which is utterly wrong.  Easily fixed though.

Reformat this section a bit, and add a note about the poor performance
of mutable arrays in the garbage collector.

Correct file names in RULES documentation

threadLabels: not public

protoize heapCheckFail()

drop Main.h

no longer used

Correct error in MacOS-specific configure code.

Fix a profiling crash on Windows.

fprint_ccs used snprintf() to avoid overflowing a buffer; on mingw32
where snprintf() doesn't exist we were just using the straight
sprintf(), which inevitably lead to a crash.  Rewritten to use a
homegrown non-overflowing string copying function - it actually looks
nicer now, anwyay.

This should have been committed along with rev. 1.36 of Main.c (and
others) yesterday, but for some reason it got left out.

Change the way Main.main is run, so it now doesn't force the return
value.  Now 'main = return undefined' will run and exit successfully.

The change affects finalizers too - but since they have type IO (), it
won't do any harm not to evaluate the ().

Fix wibble in previous commit (fixes broken bootstrap)

Fix for lexing of floating point numbers.  '9e2' should be a float.

Noticed-by: Ross Paterson.

Haskell quiz:  what should this program do?

  main = return undefined

answer: run to completion and exit successfully.  GHC erroneously
evaluates the returned value from main, which causes this example to
fail with an uncaught exception (the evaluation is even done outside
of the main exception handler!).

Support for contexts on data types and records from Derek Elkins.

Fix tryM for GHC 5.00.x and 5.02.x.

Add comment about lack of instance-support in .hi-boot

- Remove mention of MutableByteArray and ByteArray

- Add section on memory allocation in the FFI, with emphasis on how
  GHC's implementations of the various kinds of allocation perform.

----------------------------------
      Fix a long-standing egregious parser bug
	----------------------------------

	*** MERGE TO STABLE ***

	*** NB: the important part of this commit
	***	got committed by accident with an
	***	unrelated message.  This commit
	***	should be from rev 1.50 to 1.52 of RdrHsSyn


GHC has parsed

	data T String = T String

without complaint, ever since day 1!  This led to consequential
incomprehensible messages.  The fix is easy.

Document external core a bit more

Restructure documentation about undecidable instances

Buglet in external-core parsing

Use STK_CHK_NP rather than STK_CHK_GEN in the entry code for AP and
AP_STACK thunks.

The reason is that if the check fails, on return the closure might
have been blackholed (perhaps due to lazy blackholing, or even because
another thread has entered it), so we *must* enter the closure to
continue, rather than just continuing at the original entry point.

All compiler-generated thunks do this anyway, I think these are the
only cases of thunks which don't follow the rule.

Thanks to Robert Ennals for spotting, and correctly diagnosing, the
bug.

Fix typo

Fix compilation problem on mingw32