GitLab

In the case binder-swap operation (which is done in OccurAnal),
we deliberately use shadowing. But the new shadowing binder should
not inherit any fancy INLINE or NOINLINE pragmas from its parent.

This patch changes the compilation pipeline flags so that constants
are floated to the top level even in the first full laziness pass.
For some reason this was not done before.  Fixing this makes a big
improvement in 'spectral/rewrite', and has zero effect on any other
nofib benchmark.

 1. it was out of date in various ways
 2. this is not the place people look for installation instructions
 3. we have installation instructions elsewhere (e.g. the INSTALL
    file in a binary distribution)
 4. the section "layout of installed files" is now on the wiki under
    Building/Installing.

   This fixes the out of memory errors we were getting on sparc
   after the following patch:

     Fri Mar 13 03:45:16 PDT 2009  Simon Marlow <marlowsd@gmail.com>
     * Instead of a separate context-switch flag, set HpLim to zero
     Ignore-this: 6c5bbe1ce2c5ef551efe98f288483b0
     This reduces the latency between a context-switch being triggered and
     the thread returning to the scheduler, which in turn should reduce the
     cost of the GC barrier when there are many cores. 

We now use `ctypedoc` instead of `ctype` for type synonyms. `ctypedoc` was
previously only used for top-level type signatures. This change means that type
synonyms now can contain comments, just like top-level type signatures.
  
Note:
  
* I've modified `ctypedoc` so it allows implicit parameters and equational
constraints, just like ctype.
  
* Since `ctypedoc` allows nested foralls, we now allow that in type synonyms.
  
* I have inlined some productions into gentypedoc so that there is now a
non-doc version of every production with a 'doc' suffix. (Stylistic change
only, which should make the code easier to follow).
  
* It would have been nice to simplify the grammar by unifying `ctype` and 
ctypedoc` into one production, allowing comments on types everywhere (and
rejecting them after parsing, where necessary).  This is however not possible
since it leads to ambiguity. The reason is the support for comments on record
fields:
  
> data R = R { field :: Int -- ^ comment on the field }
  
If we allow comments on types here, it's not clear if the comment applies
to 'field' or to 'Int'. So we must use `ctype` to describe the type.

This avoids some showSDoc's where the String then gets converted back
into an SDoc.

Fixing #246 (pattern-match order in record patterns) made GHC go into
a black hole, by changing the order of patterm matching in
TyCon.isProductTyCon!  It turned out that GHC had been avoiding the
black hole only by the narrowest of margins up to now!

The black hole concerned the computation of which type constructors
are recursive, in TcTyDecls.calcRecFlags.  We now refrain from using
isProductTyCon there, since it triggers the black hole (very
indirectly).  See the "YUK YUK" comment in the body of calcRecFlags.

As it turns out, the fact that TyCon.isProductTyCon matched on the
algTcRec field was quite redundant, so I removed that too.  However,
without the fix to calcRecFlags, this wouldn't fix the black hole
because of the use of isRecursiveTyCon in BuildTyCl.mkNewTyConRhs.

Anyway, it's fine now.

While I was looking at the desugaring of pattern matching (fixing
Trac #3126) I finally got around to fixing another long-standing bug:
when matching in a record pattern, GHC should match left-to-right in
the programmer-specfied order, *not* left-to-right positionally in 
the original record declaration.

Needless to say, that requires a little more code. 
See Note [Record patterns] in MatchCon.lhs

Claus Reinke uncovered a long-standing bug in GHC, whereby we were
combining the pattern-match on overloaded literals, missing the fact
that an intervening pattern (for a different literal) might also 
match.  (If someone had a very odd implementation of fromInteger!)

See Note [Grouping overloaded literal patterns] in Match.lhs

If this merges smoothly to 6.10, go for it, but it's very much
a corner case.

Thank you Claus!

It turns out that, as a result of a change I made a few months ago to
the representation of SimplCont, it's easy to solve the optimisation
challenge posed by Trac #3116.  Hurrah.

Extensive comments in Note [Duplicating StrictArg].

  
  The occurrence analyser could go out to lunch in bad cases, because
  of its clever loop-breaking algorithm. This patch makes it bale out
  in bad cases.  Somewhat ad-hoc: a nicer solution would be welcome.
  
  See Note [Complexity of loop breaking] for the details.

This patch makes the specialiser propagate arities a bit more
eagerly, which avoids a spurious warning in the simplifier.

See Note [Arity decrease] in Simplify.lhs

Fix via C compilation of modules that import, say, log1p from math.h (#3117)

The list is based on preprocessing Stg.h with glibc 2.6.1 headers, and
cross-checked with the ISO C 99 standard (draft).

- Reifying a type family returns a TH family declaration
- Reifying a data constructor from a data instance attributes that
  constructor to the family (not the representation tycon)
- Ideally, we should have facilities to reify all type/data instances of a 
  given family (and the same for instances of a class).  I haven't added that
  here as it involves some API design.

Please the -Wall police by moving a variable declaration; really FIX getNumberOfProcessors() for MacOS X

This checks if darwin_HOST_OS is defined and, if so, we call
sysctlbyname() on the "hw.ncpu" property to get the processor count.