I ended up rewriting this horrible bit of code, using (yikes) lazy I/O to slurp in the source file a chunk at a time. The old code tried to read the file a chunk at a time, but failed with LANGUAGE pragmas because the parser for LANGUAGE has state and the state wasn't being saved between chunks. We're still closing the Handle eagerly, so there shouldn't be any problems here.
This is just a hack, since we don't have correct unicode output for Handles in general, I just fixed a couple of places where we were not converting to UTF-8 for output.
Now ghc --info reports whether-split-objs is supported, rather than whether the libraries were built using -split-objs.
A long-running GC would cause the timer signal to declare the system to be idle, which would cause a major GC immediately following the current GC. This only happened with +RTS -N2 or greater.
After much experimentation, I've found a formulation for HEAP_ALLOCED that (a) improves performance, and (b) doesn't have any race conditions when used concurrently. GC performance on x86_64 should be improved slightly. See extensive comments in MBlock.h for the details.
- add newAlignedPinnedByteArray# for allocating pinned BAs with arbitrary alignment - the old newPinnedByteArray# now aligns to 16 bytes Foreign.alloca will use newAlignedPinnedByteArray#, and so might end up wasting less space than before (we used to align to 8 by default). Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte aligned memory, which is enough to avoid problems with SSE instructions on x86, for example. There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes, but would have failed if the header was not a multiple of 8 (fortunately it always was, even with profiling). Also we occasionally wasted some space unnecessarily due to alignment in allocatePinned(). I haven't done anything about Foreign.malloc/mallocBytes, which will give you the same alignment guarantees as malloc() (8 bytes on Linux/x86 here).
…2983. By default, gcc on OS X will generate SSE instructions, which need things 16-byte aligned, but we don't 16-byte align things. Thus drop back to generic i686 compatibility.
…004. If you manually set HSCOLOUR_SRCS=YES then the build will fail if HsColour wasn't found.
See the Note [Dictionary-like types] in TcType for the full story here Should only affect programs that use -fdicts-cheap, for which you'll get better arities
… funny types The problem is that calls to boxyUnify would panic if the types involved contained type functions. It looks like one should wrap these calls with getLIE, although I don't really know what I am doing here
When checking argument types in a foreign call we were stupidly looking through foralls. The fix is easy. Merge to 6.10.2
The universal type variables of a data constructor are not necessarily identical to those of its parent type constructor, especially if the data type is imported. While I was at it, I did a significant refactoring to make all this traversal of types more comprehensible, by adding the data type FFoldType.