GitLab

This patch is a bit of a hack to avoid a duplicate error when checking
	class C a where
	  op :: a -> a
	  op2 x = x
(This is tcfail077)

For reasons I don't understand, the decl of op2 generates an HsDeclEntity,
and that gives a renamer error which duplicates the (better) one that 
comes from rnMethodBinds.

A better fix might be to get rid of HsDeclEntities altogether.

Adding a {-# GENERATED "SourceFile" SourceSpan #-} <expr> pragma.
This will be used to generate coverage for tool generated (or quoted) code.
The pragma states the the expression was generated/quoted from the stated
source file and source span.

- With -findexed-types, equational constraints can appear in contexts 
  wherever class predicates are allowed.
- The two argument types need to be boxed and rank 0.

Hopefully this will help to restore ability to build HEAD on GHC 5.0x systems

- The isomorphism-based newtype-deriving isn't very useful for indexed types
  right now as it rejects all recursive declarations, and we have to mark
  all indexed type instances as recurrsive as we can't guarantee that future
  instances aren't going to make them part of a recursive group.

- This patch implements deriving clauses for data instance declarations
  (toplevel and associated)
- Doesn't support standalone deriving.  This could be easily supported,
  but requires an extension of the syntax of standalone deriving clauses.
  Björn, fancy adding this?
- We cannot derive Typeable.  This seems a problem of notation, more than 
  anything else.  Why?  For a binary vanilla data type "T a b", we would 
  generate an instance Typeable2 T; ie, the instance is for the constructor
  alone.  In the case of a family instance, such as (S [a] (Maybe b)), we
  simply have no means to denote the associated constuctor.  It appears to
  require type level lambda - something like (/\a b. S [a] (Maybe b).
- Derivings are for *individual* family *instances*, not for entire families.
  Currently, I know of no simple translation of class instances for entire 
  families to System F_C.  This actually seems to be similar to implementing
  open data types à la Löh & Hinze.
- This patch only covers data types, not newtypes.

Specifically, this disables the special support in the RTS for looking up the datacon name corresponding to an address. 
Correspondingly, the debugging commads in GHCi will not be available, and neither will the '-fdebugging' flag

The :print, :sprint and :force commands for GHCi.
This set of commands allows inspection of heap structures of the bindings in the interactive environment.
This is useful to observe lazyness and specially to inspect things with undespecified polymorphic types, as happens often in breakpoints.

This patch adds dynamic breakpoints to GHCi


There is a new ':breakpoint' command to manage breakpoints.
GHCi simply uses the breakpoint api functions in ghc-api to install itself as a client.
The mechanism used by GHCi to keep track of enabled breakpoints is a simple table.

When a breakpoint is hit, a new interactive session is launched and the bindings in the breakpoint are injected. Some commands are disabled in this sub session

I found this convenient while I was extending ghci with the debugger. I wanted to put all the debugger stuff in a separate module, but I would need a huge hs-boot file to break the circular dependencies. This option seemed better

Used in the desugaring of the breakpoint primitive

The dynamic linker has been modified so that it won't panic if one of the breakpointJump functions fails to resolve.
Now, if the dynamic linker fails to find a HValue for a Name, before looking for a static symbol it will ask to

Breakpoints.lookupBogusBreakpointVal :: Name -> Maybe HValue

which returns an identity function for the Jump names or Nothing else.

A TH function might contain a call to a breakpoint function. So if it is compiled to bytecodes, the breakpoints will be desugared to 'jumps'. Whenever this code is spliced, the linker will fail to find the jumpfunctions unless there is a default.

Instrumentation gets activated by the '-fdebugging' dynflag.

All the instrumentation occurrs in the desugarer; it consists of inserting 'breakpoint' combinators at a number of places in the AST, namely: 
 - Binding sites
 - Do-notation statements 
These 'breakpoint' combinators will later be further desugared (at DsExpr) into ___Jump functions.
For more info about this and all the ghci.debugger see the page at the GHC wiki:

http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger