1. 06 May, 2007 1 commit
  2. 04 May, 2007 1 commit
  3. 03 May, 2007 1 commit
  4. 02 May, 2007 2 commits
    • Simon Marlow's avatar
      Refactoring, tidyup and improve layering · 86bec429
      Simon Marlow authored
      The stack of breakpoint resume contexts is now part of the
      InteractiveContext and managed by the GHC API.  This prevents misuse
      of the resume context by the client (e.g. resuming a breakpoint that
      isn't the topmost, which would lead to a confused IC at the least).
      
      I changed the TypeEnv in the IC to a [Id].  It only contained Ids
      anyway, and this allows us to have shadowing, which removes an ugly
      and annoying restriction.
      
      The parts of the GHC API which deal with interactive evaluation are
      now in a module of their own, InteractiveEval.
      86bec429
    • simonpj@microsoft.com's avatar
      Do not generate warnings for compiler-generated code · c94fac1c
      simonpj@microsoft.com authored
      Fixes Trac #1313
      c94fac1c
  5. 25 Apr, 2007 2 commits
  6. 17 Apr, 2007 1 commit
    • 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
  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. 21 Mar, 2007 3 commits
  9. 20 Mar, 2007 1 commit
  10. 16 Mar, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Refactor TcRnDriver, and check exports on hi-boot files · ec0b8599
      simonpj@microsoft.com authored
      This patch refactors TcRnDriver to make the top-level structure
      easier to understand.  
      
      The change was driven by Trac #924, and this patch fixes that bug.
      When comparing a module against its hs-boot file, we must ensure that
      the module exports everything that the hs-boot file exports.
      ec0b8599
  11. 11 Jan, 2007 2 commits
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Make the LiberateCase transformation understand associated types · 7aa3f524
      simonpj@microsoft.com authored
      Consider this FC program:
      	data family AT a :: *
      	data instance AT Int = T1 Int Int
      
      	f :: AT Int -> Int
      	f t = case t of DEFAULT -> <body>
      
      We'd like to replace the DEFAULT by a use of T1, so that if 
      we scrutinise t inside <body> we share the evaluation:
      
      	f t = case (t `cast` co) of T1 x y -> <body>
      
      I decided to do this as part of the liberate-case transformation,
      which is already trying to avoid redundant evals.  
      
      The new transformation requires knowledge of the family instance
      environment, so I had to extend ModGuts to carry the fam_inst_env,
      and put that envt into the liberate-case environment. 
      
      Otherwise it's all pretty straightforward.
      7aa3f524
  12. 03 Jan, 2007 1 commit
  13. 21 Dec, 2006 1 commit
  14. 11 Dec, 2006 1 commit
  15. 10 Dec, 2006 2 commits
    • mnislaih's avatar
      Breakpoint code instrumentation · 37610105
      mnislaih authored
      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
      37610105
    • mnislaih's avatar
      Playing with closures · 2c92736e
      mnislaih authored
      RtClosureInspect includes a bunch of stuff for playing with closures:
      
      - the datatype Closure is the low level representation type
      - the datatype Term is the high level representation type
      - cvObtainTerm is the main entry point, providing the Term representation of an arbitrary closure
      2c92736e
  16. 12 Dec, 2006 2 commits
  17. 07 Dec, 2006 1 commit
  18. 22 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Refactoring of where tcSimplifyTop happens · 344eb6d9
      simonpj@microsoft.com authored
      We want to do tcSimplifyTop after checkMain, because checkMain can add
      useful type information that eliminates ambiguity.  E.g.
      	main = return undefined
      
      This is the way it used to be in 6.6, and I think I mistakenly moved it
      when doing implication constraints. This patch effectively puts it back
      the way it was.
      
      Cures the cg053 failure.
      344eb6d9
  19. 10 Nov, 2006 1 commit
  20. 24 Oct, 2006 1 commit
    • andy@galois.com's avatar
      Haskell Program Coverage · d5934bbb
      andy@galois.com authored
      This large checkin is the new ghc version of Haskell
      Program Coverage, an expression-level coverage tool for Haskell.
      
      Parts:
      
       - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
       - Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
        - New Note's in Core,
            - TickBox      -- ticked on entry to sub-expression
            - BinaryTickBox  -- ticked on exit to sub-expression, depending
      	       	     -- on the boolean result.
      
        - New Stg level TickBox (no BinaryTickBoxes, though) 
      
      You can run the coverage tool with -fhpc at compile time. 
      Main must be compiled with -fhpc. 
      				      
      d5934bbb
  21. 20 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix processing of imports involving ATs with the new name parent code · 4f55ec2c
      chak@cse.unsw.edu.au. authored
      Associated types in import lists require special care and the new name
      parent code broke that.  What's the problem?  in the presence of ATs
      the name parent relation can have a depth of two (not just one as in H98).
      Here is an example:
      
        class GMapKey a where
          data GMap a :: * -> *
        instance GMapKey Int where
          data GMap Int v = GMapInt ...
      
      The data constructor GMapInt's parent is GMap whose parent in turn is the 
      class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types 
      have no parents (which is in some places in the code represented by making 
      them their own parent).
      
      I fixed this by extending the information in filterImport's occ_env and
      taking the case of associated types explicitly in consideration when 
      processing the various forms of IE items.
      4f55ec2c
  22. 19 Oct, 2006 1 commit
  23. 18 Oct, 2006 1 commit
  24. 16 Oct, 2006 1 commit
  25. 13 Oct, 2006 2 commits
    • simonpj@microsoft.com's avatar
      More refactoring in RnNames · 5ad61e14
      simonpj@microsoft.com authored
      I rather self-indulgently spent a chunk of yesterday working on 
      refactoring RnNames further.  The result is significantly simpler:
      
      * A GlobalRdrElt gets an extra field, gre_par, which records
        the parent (if any) of the name
      
      * ImportAvails has two fields deleted: imp_env and imp_parent.
        The information provided by these fields was only used when
        processing the export list; and the same information is now readily
        generated from the GlobalRdrElts in the GlobalRdrEnv
      
      I also did some tidying up; notably moving AvailEnv stuff from
      TcRnTypes to RnNames.
      
      The result is tha the compiler is some 130 lines shorter than before
      5ad61e14
    • chak@cse.unsw.edu.au.'s avatar
      Keep track of family instance modules · 311b1cdf
      chak@cse.unsw.edu.au. authored
      - Now each modules carries
        (1) a flag saying whether it contains family instance declarations and
        (2) a list of all modules further down in the import tree that contain
            family instance declarations.
        (The information is split into these two parts for the exact same reasons why
        the info about orphan modules is split, too.)
      - This is the first step to *optimised* overlap checking of family instances
        coming from imported modules.
      
      *** WARNING: This patch changes the interface file format! ***
      ***          Recompile libraries and stage2 from scratch!  ***
      311b1cdf
  26. 11 Oct, 2006 2 commits
    • Simon Marlow's avatar
      ab22f4e6
    • Simon Marlow's avatar
      Interface file optimisation and removal of nameParent · b00b5bc0
      Simon Marlow authored
      This large commit combines several interrelated changes:
      
        - IfaceSyn now contains actual Names rather than the special
          IfaceExtName type.  The binary interface file contains
          a symbol table of Names, where each entry is a (package,
          ModuleName, OccName) triple.  Names in the IfaceSyn point
          to entries in the symbol table.
      
          This reduces the size of interface files, which should
          hopefully improve performance (not measured yet).
      
          The toIfaceXXX functions now do not need to pass around
          a function from Name -> IfaceExtName, which makes that
          code simpler.
      
        - Names now do not point directly to their parents, and the
          nameParent operation has gone away.  It turned out to be hard to
          keep this information consistent in practice, and the parent info
          was only valid in some Names.  Instead we made the following
          changes:
      
          * ImportAvails contains a new field 
                imp_parent :: NameEnv AvailInfo
            which gives the family info for any Name in scope, and
            is used by the renamer when renaming export lists, amongst
            other things.  This info is thrown away after renaming.
      
          * The mi_ver_fn field of ModIface now maps to
            (OccName,Version) instead of just Version, where the
            OccName is the parent name.  This mapping is used when
            constructing the usage info for dependent modules.
            There may be entries in mi_ver_fn for things that are not in
            scope, whereas imp_parent only deals with in-scope things.
      
          * The md_exports field of ModDetails now contains
            [AvailInfo] rather than NameSet.  This gives us
            family info for the exported names of a module.
      
      Also:
      
         - ifaceDeclSubBinders moved to IfaceSyn (seems like the
           right place for it).
      
         - heavily refactored renaming of import/export lists.
      
         - Unfortunately external core is now broken, as it relied on
           IfaceSyn.  It requires some attention.
      b00b5bc0
  27. 10 Oct, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Do not filter the type envt after each GHCi stmt · afaceeff
      simonpj@microsoft.com authored
      Fixes Trac #925
      
      A new comment in TcRnDriver in tcRnStmt reads thus: 
      
      At one stage I removed any shadowed bindings from the type_env;
      they are inaccessible but might, I suppose, cause a space leak if we leave them there.
      However, with Template Haskell they aren't necessarily inaccessible.  Consider this
      GHCi session
      	 Prelude> let f n = n * 2 :: Int
      	 Prelude> fName <- runQ [| f |]
      	 Prelude> $(return $ AppE fName (LitE (IntegerL 7)))
      	 14
      	 Prelude> let f n = n * 3 :: Int
      	 Prelude> $(return $ AppE fName (LitE (IntegerL 7)))
      In the last line we use 'fName', which resolves to the *first* 'f'
      in scope. If we delete it from the type env, GHCi crashes because
      it doesn't expect that.
      
      afaceeff
    • chak@cse.unsw.edu.au.'s avatar
      Rough matches for family instances · 2a8cdc3a
      chak@cse.unsw.edu.au. authored
      - Class and type family instances just got a lot more similar.
      - FamInst, like Instance, now has a rough match signature.  The idea is the
        same: if the rough match doesn't match, there is no need to pull in the while
        tycon describing the instance (from a lazily read iface).
      - IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
        now written into the binary iface (as for class instances), as deriving it
        from the tycon (as before) would render the whole rough matching useless.
      - As a result of this, the plumbing of class instances and type instances 
        through the various environments, ModIface, ModGuts, and ModDetails is now
        almost the same.  (The remaining difference are mostly because the dfun of a
        class instance is an Id, but type instance refer to a TyCon, not an Id.)
      
      *** WARNING: The interface file format changed! ***
      ***	     Rebuild from scratch.		***
      2a8cdc3a
  28. 06 Oct, 2006 2 commits
  29. 05 Oct, 2006 1 commit