GitLab

Also renumbered the IDs and alined some things properly

and comment its invariants in Note [CoreProgram] in CoreSyn

I'm not totally convinced that CoreProgram is the right name
(perhaps CoreTopBinds might better), but it is useful to have
a clue that you are looking at the top-level bindings.

This is only a matter of a type synonym change; no deep
refactoring here.

   type family F a
   type instance F Int = Bool
   type instance F Bool = Char

In GHCi
   *TF> :kind (F Int, F Bool)
   (F Int, F Bool) :: *
   *TF> :kind! F Int
   (F Int, F Bool) :: *
   = (Bool, Char)

We could call it ":normalise" but it seemed quite nice to have an
eager version of :kind

This is just a refactoring

This addresses the rare cases where the simplifier diverges
(see the above ticket).  We were already counting how many simplifier
steps were taking place, but with no limit.  This patch adds a limit;
at which point we halt compilation, and print out useful stats. The
stats show what is begin inlined, and how often, which points you
directly to the problem.  The limit is set based on the size of the
program.

Instead of halting compilation, we could instead just inhibit
inlining, which would let compilation of the module complete. This is
a bit harder to implement, and it's likely to mean that you unrolled
the function 1143 times and then ran out of ticks; you probably don't
want to complete parsing on this highly-unrolled program.

Flags: -dsimpl-tick-factor=N.  Default is 100 (percent).
       A bigger number increases the allowed maximum tick count.

This is a follow-on to Ian's Integer-literal patch.
In effect the mk_integer Id is a free variable of a LitInteger literal.

I've also added some comments (Note [Integer literals]) in Literal.

  This is work mostly done by Daniel Winograd-Cort during his
  internship at MSR Cambridge, with some further refactoring by me.

This commit adds support to GHCi for most top-level declarations that
can be used in Haskell source files.  Class, data, newtype, type,
instance are all supported, as are Type Family-related declarations.

The current set of declarations are shown by :show bindings.  As with
variable bindings, entities bound by newer declarations shadow earlier
ones.

Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
Documentation to follow.

Fixes this problem:

Prelude> :l foo
target `foo' is not a module name or a source file
>

LitInteger now carries around the id of mkInteger, which it uses
to construct the core to build Integer literals. This way we don't
have to build in info about lots of Ids.

We also no longer have any special-casing for integer-simple, so
there is less code involved.

We had an off-by-one bug in column numbers, causing first characters
of identifiers to be duplicated.

* RWX --- --- home/prefix/gentoo/usr/lib/ghc-7.2.1/ghc
* !WX --- --- home/prefix/gentoo/usr/lib/ghc-7.2.1/libHSrts.a:AdjustorAsm.o

More info can be found here: http://www.gentoo.org/proj/en/hardened/gnu-stack.xmlSigned-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Every Haskell compilation in a package should depend on the
package-data.mk file for that package.  Then, if a package's version
number is bumped, we will recompile all the modules in the package so
that their interface files get the new version number.

This should mean that a simple 'make' will succeed in a couple of
scenarios where it didn't before:

  1. re-configuring bumps the version number of GHC, so everything
     in the ghc package (stages 1 & 2) must be recompiled.

  2. bumping the version of one of the boot packages does not require
     a make clean any more.

I have tested (1) but not (2).

LAX_DEPENDENCIES=YES disabled these new dependencies too.

This bug has been present for ages, but it only shows up in view
patterns where coercions are also involved.  Easy to fix!

It's a hack becuase we have no good reason to be sure that
these functions don't have any CAFs.  We're working on
something better, but this should fix the build (Trac #5485)

Fixes Trac #5478

In particular, use mkConApp when building the (S# i)
constructors in CorePrep

We now treat them as literals until CorePrep, when we finally
convert them into the real Core representation. This makes it a lot
simpler to implement built-in rules on them.

However, one perf test fails (parsing001) due to extra allocation.  I
want to look into this so I'm not bumping it just yet.