GitLab

I got fed up with the constant bogus output from the debugging memory
allocator in RtsUtils.c.  One problem is that we allocate memory in
constructors that then isn't tracked, because the debugging allocator
hasn't been initialised yet.

The bigger problem is that for a given piece of leaking memory it's
impossible to find out where it was allocated; however Valgrind gives
output like this:

==6967== 8 bytes in 1 blocks are still reachable in loss record 1 of 7
==6967==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==6967==    by 0x4C28522: realloc (vg_replace_malloc.c:525)
==6967==    by 0x6745E9: stgReallocBytes (RtsUtils.c:213)
==6967==    by 0x68D812: setHeapAlloced (MBlock.c:91)
==6967==    by 0x68D8E2: markHeapAlloced (MBlock.c:116)
==6967==    by 0x68DB56: getMBlocks (MBlock.c:240)
==6967==    by 0x684F55: alloc_mega_group (BlockAlloc.c:305)
==6967==    by 0x6850C8: allocGroup (BlockAlloc.c:358)
==6967==    by 0x69484F: allocNursery (Storage.c:390)
==6967==    by 0x694ABD: allocNurseries (Storage.c:436)
==6967==    by 0x6944F2: initStorage (Storage.c:217)
==6967==    by 0x673E3C: hs_init (RtsStartup.c:160)

which tells us exactly what the leaking bit of memory is.  So I don't
think we need our own debugging allocator.

Hack: dblatex normalises the name of the main input file using
os.path.realpath, which means that if we're in a linked build tree,
it find the real source files rather than the symlinks in our link
tree. This is fine for the static sources, but it means it can't
find the generated sources.

We therefore also generate the main input file, so that it really
is in the link tree, and thus dblatex can find everything.

It's not just when cleaning!

Because rtsIsProfiled is only available in stage2

This was leading to looping and excessive allocation, when the
computation should have just blocked on the black hole.  

Reported by Christian Höner zu Siederdissen <choener@tbi.univie.ac.at>
on glasgow-haskell-users.

The checkHeap function assumed the allocated part of the block contained only
alive objects and slops.  This was not true for blocks that are collected using
mark sweep.  The code in this patch skip the test for this kind of blocks.

This pulls from the upstream repos, for those packages which have
upstreams

Stops the docs going out of sync with the code.

The command stack was being extracted (by unscramble) with the outermost
type first, contrary to the comment on the function.

In case the RTS is being explicitly linked in. For #3807.

We now use the CONF_CC_OPTS_STAGEn C flags in machdepCCOpts, rather than
repeating them there.

The latter is only used when compiling .hc files, whereas we need it for
.c files too.

We used to set it only in machdepCCOpts, so this is more consistent

This also means the file is generated in a dist directory, not a
source directory.

We need to include the DPH cleaning rules, even though we don't build DPH
when GhcProfiled = YES.

Rather than it having its own specialised version

Recent versions of AS_LITERAL_IF don't like *'s.  Fix from

http://blog.gmane.org/gmane.comp.sysutils.autoconf.general/month=20100701

This change allows the client of CmdLineParser a bit more flexibility,
by giving him an arbitrary computation (not just a deprecation
message) for each flag.  

There are several clients, so there are lots of boilerplate changes.

Immediate motivation: if RTS is not profiled, we want to make 
Template Haskell illegal.  That wasn't with the old setup.

It makes the parsing simpler if we always have the same number of columns

With 30000 I was getting:
    xargs: value for -s option should be < 28153