1. 17 Apr, 2007 1 commit
  2. 10 Apr, 2007 1 commit
  3. 17 Apr, 2007 2 commits
    • Simon Marlow's avatar
      Re-working of the breakpoint support · cdce6477
      Simon Marlow authored
      This is the result of Bernie Pope's internship work at MSR Cambridge,
      with some subsequent improvements by me.  The main plan was to
      
       (a) Reduce the overhead for breakpoints, so we could enable 
           the feature by default without incurrent a significant penalty
       (b) Scatter more breakpoint sites throughout the code
      
      Currently we can set a breakpoint on almost any subexpression, and the
      overhead is around 1.5x slower than normal GHCi.  I hope to be able to
      get this down further and/or allow breakpoints to be turned off.
      
      This patch also fixes up :print following the recent changes to
      constructor info tables.  (most of the :print tests now pass)
      
      We now support single-stepping, which just enables all breakpoints.
      
        :step <expr>     executes <expr> with single-stepping turned on
        :step            single-steps from the current breakpoint
      
      The mechanism is quite different to the previous implementation.  We
      share code with the HPC (haskell program coverage) implementation now.
      The coverage pass annotates source code with "tick" locations which
      are tracked by the coverage tool.  In GHCi, each "tick" becomes a
      potential breakpoint location.
      
      Previously breakpoints were compiled into code that magically invoked
      a nested instance of GHCi.  Now, a breakpoint causes the current
      thread to block and control is returned to GHCi.
      
      See the wiki page for more details and the current ToDo list:
      
        http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
      cdce6477
    • Simon Marlow's avatar
  4. 16 Apr, 2007 6 commits
  5. 14 Apr, 2007 1 commit
  6. 12 Apr, 2007 2 commits
  7. 11 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Rationalise GhcMode, HscTarget and GhcLink · 3c22606b
      Simon Marlow authored
      This patch cleans up the GHC API, and adds some functionality: we can
      now compile to object code inside GHCi.
      
      Previously we had:
      
        data GhcMode
          = BatchCompile
          | Interactive
          | OneShot
          | JustTypecheck
          | MkDepend
        
        data HscTarget
          = HscC
          | HscAsm
          | HscJava
          | HscInterpreted
          | HscNothing
      
      There was redundancy here; if GhcMode is Interactive, then only
      HscInterpreted makes sense, and JustTypecheck required HscNothing.
      Now we have:
      
        data GhcMode
          = CompManager       -- ^ --make, GHCi, etc.
          | OneShot           -- ^ ghc -c Foo.hs
          | MkDepend          -- ^ ghc -M, see Finder for why we need this
      
      and HscTarget remains as before.
      
      Previously GhcLink looked like this:
      
        data GhcLink = NoLink | StaticLink
      
      Now we have:
      
        data GhcLink = NoLink | LinkBinary | LinkInMemory
      
      The idea being that you can have an HscTarget of HscAsm (for example)
      and still link in memory.
      
      There are two new flags:
      
        -fobject-code selects object code as the target (selects
                      either -fasm or -fvia-C, whichever is the default)
                      This can be usd with ':set' in GHCi, or on the command line.
      
        -fbyte-code   sets byte-code as the target.  Only works in GHCi.
                      One day maybe this could save the byte code in a file
                      when used outside GHCi.
      
        (names chosen for consistency with -fno-code).
      
      Changes to the GHC API: newSession no longer takes the GhcMode
      argument.  The GhcMode defaults to CompManager, which is usually what
      you want.  To do JustTypecheck now, just set hscTarget to HscNothing.
      3c22606b
  8. 10 Apr, 2007 1 commit
    • Ian Lynagh's avatar
      Don't use regexps in the GHC sources · 6c53f40f
      Ian Lynagh authored
      3 small regexps were responsible for pulling 3 packages into core-packages.
      
      The new code should also do a better job of hiding
      "call-clobbered register used" warnings.
      6c53f40f
  9. 13 Nov, 2006 1 commit
    • Aaron Tomb's avatar
      Fix external core syntax (though not full compilation) · de777ba4
      Aaron Tomb authored
      This patch updates the External Core creator, pretty-printer, and parser to
      agree on a concrete syntax for External Core, including the constructs
      required by the change to System FC. Code to create valid ASTs from External
      Core files will come later, as will bits for renaming, typechecking, and
      desugaring.
      de777ba4
  10. 06 Apr, 2007 1 commit
  11. 04 Apr, 2007 3 commits
  12. 03 Apr, 2007 1 commit
  13. 02 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make type-tidying work for coercion variables · f2b02ce8
      simonpj@microsoft.com authored
      When tidying a TyVar binder, we must tidy its kind if it's a coercion
      variable!  I had forgotten to do this, which is a serious bug.  As a
      result some more complicated programs were getting a Lint error when
      reading in interface files.  Score one for Core Lint!
      
      f2b02ce8
  14. 01 Apr, 2007 1 commit
  15. 02 Apr, 2007 1 commit
  16. 30 Mar, 2007 2 commits
    • simonpj@microsoft.com's avatar
      The ru_local field of a CoreRule is False for implicit Ids · ec81fdde
      simonpj@microsoft.com authored
      	MERGE to 6.6.1
      
      For class-ops, record selectors, data constructors, we want the ru_local
      field of the Rule to be False.  We do not attach the rule to the binding
      for the Id, because there simply isn't a binding until the code gen stage.
      
      (NB: the ru_local field is different to the orphan-hood of the rule.)
      
      This fixes a bug that meant that RULES on class ops were never exported.
      ec81fdde
    • simonpj@microsoft.com's avatar
      Match the type of an Id during rule matching · 206b7529
      simonpj@microsoft.com authored
      	Please MERGE to 6.6.1
      
      Consider this RULE
          forall (c::Char->Int) (x::Char). 
      	f (c x) = "RULE FIRED"
      
      Well, this should only match on arguments of the specified type
      But we simply weren't checking this condition before.  Now we are.
      
      Test is simplrun008
      
      206b7529
  17. 28 Mar, 2007 2 commits
  18. 27 Mar, 2007 5 commits
    • wolfgang.thaller@gmx.net's avatar
      Make GHC main program depend on the libHSghc_dyn when GhcBuildDylibs==YES · be96a4fa
      wolfgang.thaller@gmx.net authored
      When building a dynamic GHC, we obviously want to build the dynamic library
      libHSghc_dyn.[so|dylib] before building the compiler executable.
      
      MERGE TO STABLE
      be96a4fa
    • Simon Marlow's avatar
      make GHCi use base:Prelude, not just Prelude · 4439532f
      Simon Marlow authored
      The module that GHCi uses for its default scope should be exactly
      base:Prelude, not whatever Prelude is found on the search path.
      4439532f
    • Simon Marlow's avatar
      more improvements for #1119 · 075a7bad
      Simon Marlow authored
      When GHCi compiles its code framgents for setting buffering, it wants
      to refer to base:System.IO rather than whatever System.IO is on the
      search path, unfortunately there's no way to do this in source code,
      so to hack around it we set the search path to empty before compiling
      these expressions (not forgetting to flush the finder cache
      afterward).
      075a7bad
    • Simon Marlow's avatar
      partial fix for #1119 · 1e8ae3f0
      Simon Marlow authored
      Unless we're in one-shot mode, emit an error if we attempt to
      demand-load interfaces for home modules.  This can only happen in one
      way (that I'm aware of): typing a qualified name at the GHCi prompt
      that refers to a module that isn't loaded.  Previously you got a
      cryptic message about not finding an interface file, now you get:
      
      Prelude> Foo.a
      
      <interactive>:1:0:
          attempting to use module `Foo' (Foo.hs) which is not loaded
      
      Of course you can still refer to package modules like this without
      loading them explicitly, only home modules are affected, and the
      behaviour is exactly the same as if you try to ':browse Foo' and
      Foo isn't loaded.
      1e8ae3f0
    • simonpj@microsoft.com's avatar
  19. 23 Mar, 2007 4 commits
  20. 22 Mar, 2007 3 commits