GitLab

Sometimes parts of a source file come from different places due to
preprocessing, and the lines can overlap.

Now I can single step through Happy-generated parsers

See bug #1295

Now that constructor info tables contain the name of the constructor,
we can generate useful heap profiles without requiring the whole
program and libraries to be compiled with -prof.  So now, "+RTS -hT"
generates a heap profile for any program, dividing the profile by
constructor.  It wouldn't be hard to add support for grouping
constructors by module, or to restrict the profile to certain
constructors/modules/packages.

This means that for the first time we can get heap profiles for GHCi,
which was previously impossible because the byte-code
interpreter and linker don't work with -prof.

It looks like this was accidentally replaced with '?' in the patch
"HsSyn clean up for indexed types".  (see bug #1294)

If you compiled a program with -ticky and ran it with:
./foo +RTS -rstderr -RTS
the result would be a segfault. This was because the RTS interprets stderr to
mean "use debugBelch to print out messages," and sets the ticky file pointer
to NULL as a result, but PrintTickyInfo (the function in Ticky.c that prints
out the ticky report) wasn't checking for NULL.

I changed PrintTickyInfo to check whether the ticky file pointer is NULL and 
output to stderr if so.

Also removed an unused import from CodeOutput.lhs.

I introduced a bug yesterday when I changed the way tidying up was performed.
As a result of tidying,  cvObtainTerm could be returning types 
with regular tyvars inside, which never should.

But actually, it's better if we do not do the tidying up, in order to 
keep the tyvar names from the environment.
New names will be introduced only when an existential is found, which
is not so common. In this case the user will see a funny name. 
Is that really an issue?

This speeds up the debugger quite a bit, we're now only about 30%
slower than ordinary GHCi, and still adding breakpoints to every
sub-expression.  Also we now get to see the free variables in
recursive bindings, which wasn't working properly before.

so completion can now complete names of local bindings

  
  Stopped at ../Test3.hs:(1,0)-(2,30)
  _result :: [a]
  [../Test3.hs:(1,0)-(2,30)] *Main> _result
  
  <interactive>:1:0:
      Ambiguous type variable `a' in the constraint:
        `Show a' arising from a use of `print' at <interactive>:1:0-6
      Cannot resolve unkonwn runtime types: a
      Use :print or :force to determine these types

For more details, see test print019

Also share the code that extends the InteractiveContext between
tcRnStmt and GHC.extendEnvironment.

Strictly speaking most of pprintClosureCommand should be exported by
the GHC API, but this is a step in the right direction.

Now, the type checker won't attempt to generalise over the skolem
variables in the interactive bindings.  If we end up trying to show
one of these types, there will be an unresolved predicate 'Show t'
which causes a type error (albeit a strange one, I'll fix that
later).