1. 07 Sep, 2007 1 commit
    • nr@eecs.harvard.edu's avatar
      refactor duplicated code in main/HscMain · e9d303dc
      nr@eecs.harvard.edu authored
        I kept making mistakes because all the ZipCfg and CPS stuff
        was called from two different places (compiling Haskell and 
        compiling Cmm).  Now it is called from a single place, and therefore
        successfully turned off by default.
      
        I still don't know why turning it on causes rts/Apply.cmm not to
        compile; that development is new since yesterday.
      e9d303dc
  2. 06 Sep, 2007 1 commit
    • nr@eecs.harvard.edu's avatar
      massive changes to add a 'zipper' representation of C-- · 16a2f6a8
      nr@eecs.harvard.edu authored
      Changes too numerous to comment on, but here is some old history that
      I saved: 
      
      
      Wed Aug 15 11:07:13 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * type synonyms made consistent with new Cmm types
      
          M ./compiler/nativeGen/MachInstrs.hs -2 +2
      
      Mon Aug 20 19:22:14 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * pushing return info beyond cmm into codegen
      
          M ./compiler/codeGen/Bitmap.hs r3
          M ./compiler/codeGen/CgBindery.lhs r3
          M ./compiler/codeGen/CgCallConv.hs r3
          M ./compiler/codeGen/CgCase.lhs r3
          M ./compiler/codeGen/CgClosure.lhs r3
          M ./compiler/codeGen/CgCon.lhs r3
          M ./compiler/codeGen/CgExpr.lhs r3
          M ./compiler/codeGen/CgForeignCall.hs -6 +7 r3
          M ./compiler/codeGen/CgHeapery.lhs r3
          M ./compiler/codeGen/CgHpc.hs +1 r3
          M ./compiler/codeGen/CgInfoTbls.hs r3
          M ./compiler/codeGen/CgLetNoEscape.lhs r3
          M ./compiler/codeGen/CgMonad.lhs r3
          M ./compiler/codeGen/CgParallel.hs r3
          M ./compiler/codeGen/CgPrimOp.hs +3 r3
          M ./compiler/codeGen/CgProf.hs r3
          M ./compiler/codeGen/CgStackery.lhs r3
          M ./compiler/codeGen/CgTailCall.lhs r3
          M ./compiler/codeGen/CgTicky.hs r3
          M ./compiler/codeGen/CgUtils.hs -1 +1 r3
          M ./compiler/codeGen/ClosureInfo.lhs r3
          M ./compiler/codeGen/CodeGen.lhs r3
          M ./compiler/codeGen/SMRep.lhs r3
          M ./compiler/nativeGen/AsmCodeGen.lhs -2 +2 r1
          M ./compiler/nativeGen/MachCodeGen.hs -3 +3 r1
          M ./compiler/nativeGen/MachInstrs.hs r1
          M ./compiler/nativeGen/MachRegs.lhs r1
          M ./compiler/nativeGen/NCGMonad.hs r1
          M ./compiler/nativeGen/PositionIndependentCode.hs r1
          M ./compiler/nativeGen/PprMach.hs r1
          M ./compiler/nativeGen/RegAllocInfo.hs r1
          M ./compiler/nativeGen/RegisterAlloc.hs r1
      
      Mon Aug 20 20:54:41 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * put CmmReturnInfo into a CmmCall (and related types)
      
          M ./compiler/cmm/Cmm.hs -2 +1 r3
          M ./compiler/cmm/CmmBrokenBlock.hs -13 +12 r1
          M ./compiler/cmm/CmmCPS.hs -3 +3
          M ./compiler/cmm/CmmCPSGen.hs -8 +6 r1
          M ./compiler/cmm/CmmLint.hs -1 +1
          M ./compiler/cmm/CmmLive.hs -1 +1
          M ./compiler/cmm/CmmOpt.hs -3 +3
          M ./compiler/cmm/CmmParse.y -6 +6 r3
          M ./compiler/cmm/PprC.hs -3 +3
          M ./compiler/cmm/PprCmm.hs -7 +4 r2
          M ./compiler/codeGen/CgForeignCall.hs -7 +6 r2
          M ./compiler/codeGen/CgHpc.hs -1 r1
          M ./compiler/codeGen/CgPrimOp.hs -3 r1
          M ./compiler/codeGen/CgUtils.hs -1 +1 r1
          M ./compiler/nativeGen/AsmCodeGen.lhs -2 +2
          M ./compiler/nativeGen/MachCodeGen.hs -3 +3 r1
      
      Tue Aug 21 18:09:13 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * add call info in nativeGen
      
          M ./compiler/nativeGen/AsmCodeGen.lhs r1
          M ./compiler/nativeGen/MachInstrs.hs r1
          M ./compiler/nativeGen/MachRegs.lhs r1
          M ./compiler/nativeGen/NCGMonad.hs r1
          M ./compiler/nativeGen/PositionIndependentCode.hs r1
          M ./compiler/nativeGen/PprMach.hs r1
          M ./compiler/nativeGen/RegAllocInfo.hs r1
      
      Wed Aug 22 16:41:58 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * ListGraph is now a newtype, not a synonym
        The resultant bookkeepping is unenviable, but the change
        greatly simplifies our ability to make Cmm things propertly
        Outputable for both list-graph and zipper-graph representations.
      
          M ./compiler/cmm/Cmm.hs -5 +3
          M ./compiler/cmm/CmmCPS.hs -2 +2
          M ./compiler/cmm/CmmCPSGen.hs -1 +1
          M ./compiler/cmm/CmmContFlowOpt.hs -3 +3
          M ./compiler/cmm/CmmCvt.hs -2 +2
          M ./compiler/cmm/CmmInfo.hs -2 +3
          M ./compiler/cmm/CmmLint.hs -1 +1
          M ./compiler/cmm/CmmOpt.hs -2 +2
          M ./compiler/cmm/PprC.hs -1 +1
          M ./compiler/cmm/PprCmm.hs -5 +8
          M ./compiler/cmm/PprCmmZ.hs -7 +1
          M ./compiler/codeGen/CgMonad.lhs -1 +1
          M ./compiler/nativeGen/AsmCodeGen.lhs -15 +15
          M ./compiler/nativeGen/MachCodeGen.hs -2 +2
          M ./compiler/nativeGen/PositionIndependentCode.hs -6 +6
          M ./compiler/nativeGen/PprMach.hs -3 +2
          M ./compiler/nativeGen/RegAllocColor.hs +1
          M ./compiler/nativeGen/RegAllocLinear.hs -4 +5
          M ./compiler/nativeGen/RegCoalesce.hs -6 +6
          M ./compiler/nativeGen/RegLiveness.hs -12 +12
      
      Thu Aug 23 13:44:49 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * diagnostic assistance in case fromJust fails
      
          M ./compiler/nativeGen/MachCodeGen.hs -2 +5
      
      Thu Aug 23 14:07:28 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * give every block, even the first, a label
          With branch-chain elimination, the first block of a procedure
          might be the target of a branch.  This actually happens to 
          a dozen or more procedures in the run-time system.
      
          M ./compiler/nativeGen/PprMach.hs -8 +3
      
      Fri Aug 24 17:27:04 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * clean up the code in PprMach
      
          M ./compiler/nativeGen/PprMach.hs -16 +14
      
      Fri Aug 24 19:35:03 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * a bunch of impedance matching to get the compiler to build, plus 
         * the plus is diagnostics for unreachable code, which required
           moving a lot of prettyprinting code
      
          M ./compiler/cmm/Cmm.hs -7 +5
          M ./compiler/cmm/CmmCPSZ.hs -1 +1
          M ./compiler/cmm/CmmCvt.hs -8 +8
          M ./compiler/cmm/CmmParse.y -4 +3
          M ./compiler/cmm/MkZipCfg.hs -19 +9
          M ./compiler/cmm/PprCmmZ.hs -118 +4
          M ./compiler/cmm/ZipCfg.hs -1 +13
          M ./compiler/cmm/ZipCfgCmm.hs -10 +129
          M ./compiler/main/HscMain.lhs -4 +4
          M ./compiler/nativeGen/NCGMonad.hs -2 +2
          M ./compiler/nativeGen/RegAllocInfo.hs -3 +3
      
      Fri Aug 31 14:38:02 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * fix a warning about an import
      
          M ./compiler/nativeGen/RegAllocColor.hs -1 +1
      16a2f6a8
  3. 05 Sep, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1650: ".boot modules interact badly with the ghci debugger" · e2782137
      Simon Marlow authored
      In fact hs-boot files had nothing to do with it: the problem was that
      GHCi would forget the breakpoint information for a module that had
      been reloaded but not recompiled.  It's amazing that we never noticed
      this before.
      
      The ModBreaks were in the ModDetails, which was the wrong place.  When
      we avoid recompiling a module, ModDetails is regenerated from ModIface
      by typecheckIface, and at that point it has no idea what the ModBreaks
      should be, so typecheckIface made it empty.  The right place for the
      ModBreaks to go is with the Linkable, which is retained when
      compilation is avoided.  So now I've placed the ModBreaks in with the
      CompiledByteCode, which also makes it clear that only byte-code
      modules have breakpoints.
      
      This fixes break022/break023
      e2782137
  4. 04 Sep, 2007 2 commits
  5. 03 Sep, 2007 1 commit
  6. 01 Sep, 2007 1 commit
  7. 26 Aug, 2007 1 commit
    • Simon Marlow's avatar
      Refactoring only: remove [Id] field from ForeignStubs · 663b3914
      Simon Marlow authored
      We used to pass the list of top-level foreign exported bindings to the
      code generator so that it could create StablePtrs for them in the
      stginit code.  Now we don't use stginit unless profiling, and the
      StablePtrs are generated by C functions marked with
      attribute((constructor)).  This patch removes various bits associated
      with the old way of doing things, which were previously left in place
      in case we wanted to switch back, I presume.  Also I refactored
      dsForeigns to clean it up a bit.
      663b3914
  8. 16 Aug, 2007 1 commit
  9. 11 Aug, 2007 1 commit
  10. 16 Jul, 2007 1 commit
  11. 14 Jul, 2007 1 commit
    • David Waern's avatar
      FIX panic from the GHC API · bf2f000a
      David Waern authored
      In hscFileCheck, initialize md_vect_info with noVectInfo instead of
      a panic value, since this is a strict field.
      bf2f000a
  12. 05 Jul, 2007 1 commit
  13. 29 Jun, 2007 1 commit
  14. 27 Jun, 2007 2 commits
    • Michael D. Adams's avatar
      d31dfb32
    • Michael D. Adams's avatar
      First pass at implementing info tables for CPS · f96e9aa0
      Michael D. Adams authored
      This is a fairly complete implementation, however
      two 'panic's have been placed in the critical path
      where the implementation is still a bit lacking so
      do not expect it to run quite yet.
      
      One call to panic is because we still need to create
      a GC block for procedures that don't have them yet.
      (cmm/CmmCPS.hs:continuationToProc)
      
      The other is due to the need to convert from a
      ContinuationInfo to a CmmInfo.
      (codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable)
      (codeGen/CgInfoTbls.hs:emitReturnTarget)
      f96e9aa0
  15. 10 May, 2007 1 commit
  16. 29 Jun, 2007 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Further compileToCore improvements · 78f4da28
      chevalier@alum.wellesley.edu authored
      Per suggestions from Simon M:
      
      * Changed GHC.checkModule so that it doesn't call depanal.
      * Changed GHC.checkModule to optionally return Core bindings
      as a component of the CheckedModule that it returns (and 
      resulting changes to HscMain.hscFileCheck).
      * As a result, simplified GHC.compileToCore and changed it
      to load the given file so that the caller doesn't have to.
      78f4da28
  17. 07 May, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Add VectInfo to HPT · e5f78a4a
      chak@cse.unsw.edu.au. authored
        I am putting this patch (as the previous VectInfo patch) straight away
        into the head to avoid the kind of merging disaster we had with the FC
        branch.  The patch does not interfere with any other functionality and
        hence should cause no harm in the head.
      e5f78a4a
  18. 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
    • Simon Marlow's avatar
      Print the "skipping" messages at verbosity 2 again · e1f7582a
      Simon Marlow authored
      This was accidentally changed to 1 in the HEAD a while ago, the
      behaviour is now the same as 6.6.x again.
      e1f7582a
  19. 25 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Keep track of free type variables in the interactive bindings · 671b39c5
      Simon Marlow authored
      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).
      671b39c5
  20. 19 Apr, 2007 1 commit
  21. 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
  22. 28 Mar, 2007 2 commits
  23. 12 Jan, 2007 1 commit
  24. 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
  25. 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
  26. 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
  27. 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
  28. 06 Oct, 2006 1 commit
  29. 05 Oct, 2006 1 commit
  30. 20 Sep, 2006 1 commit
    • 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
  31. 04 Aug, 2006 1 commit
  32. 18 Aug, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Fall over more gracefully when there's a Template Haskell error · 7a59afce
      simonpj@microsoft.com authored
      For a long time, Template Haskell has fallen over in a very un-graceful
      way (i.e. panic) even when it encounters a programmer error.  In particular,
      when DsMeta converts HsSyn to TH syntax, it may find Haskell code that
      TH does not understand. This should be reported as a normal programmer
      error, not with a compiler panic!
      
      Originally the desugarer was supposed to never generate error
      messages, but this TH desugaring thing does make it do so.  And in
      fact, for other reasons, the desugarer now uses the TcRnIf monad, the
      common monad used by the renamer, typechecker, interface checker, and
      desugarer.  
      
      This patch completes the job, by 
       - allowing the desugarer to generate errors
       - re-plumbing the error handling to take account of this
       - making DsMeta use the new facilities to report error gracefully
      
      Quite a few lines of code are touched, but nothing deep is going on.
      
      Fixes Trac# 760.
      7a59afce
  33. 11 Aug, 2006 1 commit
  34. 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
  35. 02 Jul, 2006 1 commit
    • Jan Rochel's avatar
      Add %local-tag to external core output · 99bab7d8
      Jan Rochel authored
      Hello, this is my first patch contributed to GHC. If there are any
      inadequacies about it (maybe like this introductory disclaimer), please
      let me know about it.
      
      So, the need for this patch arose, while I was involved with processing
      hcr files (external core output) and I noticed, that the output didn't
      fully conform to the specification [1].
      No %local-tags were used, which turned out to be a real nuisance as it
      was not possible to determine which VDEFs can be erased in a further
      optimization process and which ones are exported by the module.
      
      Since the specification does not define the meaning of the %local-tag, I
      assume, it makes sense, that it tags all functions, that are not
      exported by the module.
      
      The patch does not fully comply to the specification, as in my
      implementation a local tag may appear before a VDEF but not before a
      VDEFG.
      
      [1] An External Representation for the GHC Core Language
          (DRAFT for GHC5.02), page 3, line 1
      
      Greetings
      Jan
      99bab7d8