1. 03 May, 2007 1 commit
  2. 02 May, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Import fiddling · c916244f
      simonpj@microsoft.com authored
      c916244f
    • 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
  3. 30 Apr, 2007 1 commit
    • andy@galois.com's avatar
      Changing internal data structures used by Hpc · 55a5d8d9
      andy@galois.com authored
       - .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file.
       - .mix files now have (the same) hash number.
      
      This changes allow different binaries that use the same module compiled in the same way
      to share coverage information.
      55a5d8d9
  4. 25 Apr, 2007 2 commits
  5. 24 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Breakpoints: get the names of the free variables right · 367b0590
      Simon Marlow authored
      Previously we relied on the names of the Ids attached to a tick being
      the same as the names of the original variables in the source code.
      Sometimes this worked, sometimes it didn't because the simplifier
      would inline away the Id.  So now we do this properly and retain the
      original OccNames from the source code for each breakpoint, and use
      these to construct the new Ids when we stop.
      
      Doing this involved moving the tracking of in-scope variables from the
      desugarer to the coverage pass.
      367b0590
  6. 18 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Various cleanups and improvements to the breakpoint support · 38e7ac3f
      Simon Marlow authored
        - move parts of the debugger implementation below the GHC API where
          they belong.  There is still more in Debugger that violates the
          layering, hopefully I'll get to that later.
      
        - instead of returning an IO action from runStmt for resuming,
          return a ResumeHandle that is passed to GHC.resume.
      
        - breakpoints now return [Name] which is displayed in the same
          way as when a binding statement is executed.
      
        - :load, :add, :reload now clear the active breakpoints and context
      
        - :break gives a sensible error when used on a non-interpreted module
      
        - export breakpoint-related types from GHC
      
        - remove a bunch of layer-violating imports from InteractiveUI
      
        - remove some more vestiges of the old breakpoint code (topLevel in
          the GHCi state).
      
        - remove TickTree and use a simple array instead, cached per module
      38e7ac3f
  7. 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
  8. 11 Jan, 2007 3 commits
    • mnislaih's avatar
      This patch teaches ghci to announce that a module has beeen loaded in debugging mode · d6b89927
      mnislaih authored
      Usually ghci announces when a module has been loaded interpreted. Now it will also announce it when the module has been instrumented for debugging
      d6b89927
    • simonpj@microsoft.com's avatar
      Comments only · ade40ed3
      simonpj@microsoft.com authored
      ade40ed3
    • 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
  9. 10 Dec, 2006 1 commit
    • 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
  10. 25 Nov, 2006 1 commit
  11. 22 Nov, 2006 1 commit
  12. 02 Nov, 2006 1 commit
  13. 01 Nov, 2006 1 commit
  14. 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
  15. 18 Oct, 2006 1 commit
  16. 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
  17. 11 Oct, 2006 2 commits
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
    • 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
  18. 10 Oct, 2006 1 commit
    • 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
  19. 06 Oct, 2006 2 commits
  20. 20 Sep, 2006 6 commits
    • chak@cse.unsw.edu.au.'s avatar
      Import/export of data constructors in family instances · a835e9fa
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:50:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Import/export of data constructors in family instances
        Tue Sep 12 13:54:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Import/export of data constructors in family instances
          - Data constructors of a data/newtype family F can be exported and imported
            by writing F(..) or F(ConName).
          - This appears the most natural from a user's persepctive - although, it has a
            slightly different flavour than similar import/exports items for closed data 
            types.  The data constructors denoted by F(..) vary in dependence on the 
            visible data instances.
          - This has been non-trivial to achieve as RnNames derives its knowledge of what
            sub-binders an F(..) item exports/imports from the relation specified by 
            Name.nameParent - ie, the constructors of a data/newtype instance need to 
            have the family name (not the internal name of the representation tycon) as 
            their parent.
          
          *** WARNING: This patched changes the iface format! ***
          ***          Please re-compile from scratch!	    ***
      a835e9fa
    • chak@cse.unsw.edu.au.'s avatar
      ATs are now implicitTyThings · 14a3631d
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:36:03 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * ATs are now implicitTyThings
        Tue Sep  5 21:09:54 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * ATs are now implicitTyThings
      14a3631d
    • chak@cse.unsw.edu.au.'s avatar
      Straightened out implicit coercions for indexed types · d76c18e0
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:35:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Straightened out implicit coercions for indexed types
        Mon Sep  4 23:46:14 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Straightened out implicit coercions for indexed types
          - HscTypes.implicitTyThings and LoadIface.ifaceDeclSubBndrs now
            include the coercion of indexed data/newtypes.
          - Name generation for the internal names of indexed data/newtypes now uses
            the same counter that generates the dfun unique indexes (ie, class and type
            instances are counted with the one counter).  We could make this two 
            separate counters if that's what's preferred.
          - The unique index of a data/newtype instances needs to go into the iface, so
            that we can generate the same names on slurping in the iface as when the
            original module was generated.  This is a bit yucky, but I don't see a way
            to avoid that (other than putting the full blown internal tycon name and 
            coercion name into the iface, which IMHO would be worse).
          - The predicate for when a datacon has a wrapper didn't take GADT
            equations nor whether it comes froma  family instance into account.
          
          *** WARNING!  This patch changed the interface file format. ***
          ***           Please recompile from scratch.                ***
      d76c18e0
    • chak@cse.unsw.edu.au.'s avatar
      Make sure ATs are included into the temporary env for tc knot tying · f94a8dbd
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:03:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Make sure ATs are included into the temporary env for tc knot tying
        Wed Aug 16 17:52:40 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Make sure ATs are included into the temporary env for tc knot tying
      f94a8dbd
    • chak@cse.unsw.edu.au.'s avatar
      Extend Class.Class to include the TyCons of ATs · bb106f28
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 18:58:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extend Class.Class to include the TyCons of ATs
        Wed Aug 16 16:15:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extend Class.Class to include the TyCons of ATs
      bb106f28
    • chak@cse.unsw.edu.au.'s avatar
      newtype fixes, coercions for non-recursive newtypes now optional · c94408e5
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 14:24:27 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * newtype fixes, coercions for non-recursive newtypes now optional
        Sat Aug  5 21:19:58 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * newtype fixes, coercions for non-recursive newtypes now optional
          Fri Jul  7 06:11:48 EDT 2006  kevind@bu.edu
      c94408e5
  21. 04 Aug, 2006 1 commit
  22. 23 Aug, 2006 1 commit
  23. 11 Aug, 2006 1 commit
  24. 25 Jul, 2006 1 commit
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  25. 04 Jul, 2006 2 commits
  26. 18 Apr, 2006 1 commit
  27. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab