1. 23 Nov, 2012 1 commit
  2. 16 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Some alpha renaming · cd33eefd
      ian@well-typed.com authored
      Mostly d -> g (matching DynFlag -> GeneralFlag).
      Also renamed if* to when*, matching the Haskell if/when names
      cd33eefd
  3. 15 Jul, 2012 1 commit
  4. 18 Jun, 2012 1 commit
  5. 12 Jun, 2012 1 commit
  6. 11 Jun, 2012 1 commit
    • Ian Lynagh's avatar
      Pass DynFlags to the LogAction · 5716a2f8
      Ian Lynagh authored
      A side-effect is that we can no longer use the LogAction in
      defaultErrorHandler, as we don't have DynFlags at that point.
      But all that defaultErrorHandler did is to print Strings as
      SevFatal, so now it takes a 'FatalMessager' instead.
      5716a2f8
  7. 29 May, 2012 1 commit
    • Ian Lynagh's avatar
      Replace printDump with a new Severity · 78252479
      Ian Lynagh authored
      We now use log_action with severity SevDump, rather than calling
      printDump. This means that what happens to dumped info is now under
      the control of the GHC API user, rather than always going to stdout.
      78252479
  8. 25 Apr, 2012 1 commit
  9. 28 Mar, 2012 1 commit
  10. 19 Jan, 2012 1 commit
  11. 12 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Implememt -fdefer-type-errors (Trac #5624) · 5508ada4
      Simon Peyton Jones authored
      This patch implements the idea of deferring (most) type errors to
      runtime, instead emitting only a warning at compile time.  The
      basic idea is very simple:
      
       * The on-the-fly unifier in TcUnify never fails; instead if it
         gets stuck it emits a constraint.
      
       * The constraint solver tries to solve the constraints (and is
         entirely unchanged, hooray).
      
       * The remaining, unsolved constraints (if any) are passed to
         TcErrors.reportUnsolved.  With -fdefer-type-errors, instead of
         emitting an error message, TcErrors emits a warning, AND emits
         a binding for the constraint witness, binding it
         to (error "the error message"), via the new form of evidence
         TcEvidence.EvDelayedError.  So, when the program is run,
         when (and only when) that witness is needed, the program will
         crash with the exact same error message that would have been
         given at compile time.
      
      Simple really.  But, needless to say, the exercise forced me
      into some major refactoring.
      
       * TcErrors is almost entirely rewritten
      
       * EvVarX and WantedEvVar have gone away entirely
      
       * ErrUtils is changed a bit:
           * New Severity field in ErrMsg
           * Renamed the type Message to MsgDoc (this change
             touches a lot of files trivially)
      
       * One minor change is that in the constraint solver we try
         NOT to combine insoluble constraints, like Int~Bool, else
         all such type errors get combined together and result in
         only one error message!
      
       * I moved some definitions from TcSMonad to TcRnTypes,
         where they seem to belong more
      5508ada4
  12. 03 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Major refactoring of CoAxioms · 98a642cf
      Simon Peyton Jones authored
      This patch should have no user-visible effect.  It implements a
      significant internal refactoring of the way that FC axioms are
      handled.  The ultimate goal is to put us in a position to implement
      "pattern-matching axioms".  But the changes here are only does
      refactoring; there is no change in functionality.
      
      Specifically:
      
       * We now treat data/type family instance declarations very,
         very similarly to types class instance declarations:
      
         - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
           FamInstEnv.FamInst.  This change does affect the GHC API, but
           for the better I think.
      
         - Previously, each family type/data instance declaration gave rise
           to a *TyCon*; typechecking a type/data instance decl produced
           that TyCon.  Now, each type/data instance gives rise to
           a *FamInst*, by direct analogy with each class instance
           declaration giving rise to a ClsInst.
      
         - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
           contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
           in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
           two types, whereas the FamInst relates directly to the Haskell source
           language construct, and always has a function (F tys) on the LHS.
      
         - Just as a DFunId has its own declaration in an interface file, so now
           do CoAxioms (see IfaceSyn.IfaceAxiom).
      
         These changes give rise to almost all the refactoring.
      
       * We used to have a hack whereby a type family instance produced a dummy
         type synonym, thus
            type instance F Int = Bool -> Bool
         translated to
            axiom FInt :: F Int ~ R:FInt
            type R:FInt = Bool -> Bool
         This was always a hack, and now it's gone.  Instead the type instance
         declaration produces a FamInst, whose axiom has kind
            axiom FInt :: F Int ~ Bool -> Bool
         just as you'd expect.
      
       * Newtypes are done just as before; they generate a CoAxiom. These
         CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
         unlike the ones coming from family instance declarations.  See
         Note [Implicit axioms] in TyCon
      
      On the whole the code gets significantly nicer.  There were consequential
      tidy-ups in the vectoriser, but I think I got them right.
      98a642cf
  13. 18 Nov, 2011 1 commit
  14. 13 Nov, 2011 1 commit
  15. 10 Nov, 2011 1 commit
  16. 05 Nov, 2011 1 commit
    • GregWeber's avatar
      addDependentFile #4900 · b994313a
      GregWeber authored
      Let GHC know about an external dependency that Template Haskell uses
      so that GHC can recompile when the dependency changes.
      No support for ghc -M
      
      There is a corresponding addition to the template-haskell library
      b994313a
  17. 04 Nov, 2011 1 commit
  18. 25 Oct, 2011 1 commit
  19. 21 Sep, 2011 1 commit
  20. 18 Aug, 2011 1 commit
  21. 03 Aug, 2011 1 commit
  22. 02 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Change the representation of export lists in .hi files · fe44af73
      Simon Peyton Jones authored
      Currently export list in .hi files are partitioned by module
        export M T(C1,C2)
               N f,g
      In each list we only have OccNames, all assumed to come from
      the parent module M or N resp.
      
      This patch changes the representatation so that export lists
      have full Names:
        export M.T(M.C1,M.C2), N.f, N.g
      
      Numerous advatages
        * AvailInfo no longer needs to be parameterised; it always
          contains Names
      
        * Fixes Trac #5306.  This was the main provocation
      
        * Less to-and-fro conversion when reading interface files
      
      It's all generally simpler.  Interface files should not get bigger,
      becuase they have a nice compact representation for Names.
      fe44af73
  23. 20 Jul, 2011 1 commit
    • Simon Marlow's avatar
      Fix #481: use a safe recompilation check when Template Haskell is · 48bc81ad
      Simon Marlow authored
      being used.
      
      We now track whether a module used any TH splices in the ModIface (and
      at compile time in the TcGblEnv and ModGuts).  If a module used TH
      splices last time it was compiled, then we ignore the results of the
      normal recompilation check and recompile anyway, *unless* the module
      is "stable" - that is, none of its dependencies (direct or indirect)
      have changed.  The stability test is pretty important - otherwise ghc
      --make would always recompile TH modules even if nothing at all had
      changed, but it does require some extra plumbing to get this
      information from GhcMake into HscMain.
      
      test in driver/recomp009
      48bc81ad
  24. 30 Jun, 2011 1 commit
  25. 18 Jun, 2011 5 commits
  26. 03 Jun, 2011 1 commit
  27. 14 Sep, 2010 1 commit
  28. 13 Sep, 2010 1 commit
  29. 20 Mar, 2010 1 commit
  30. 21 Aug, 2009 1 commit
  31. 14 Aug, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Improve fix to Trac #3007 · 32868195
      simonpj@microsoft.com authored
      This patch tides up Ian's fix a little. In particular, if if you
      {-# SOURCE #-} import a module from a different package, you now 
      get a much more civlised error message.
      32868195
  32. 13 Aug, 2009 1 commit
    • Ian Lynagh's avatar
      Only look up whether a module's SOURCE-imported if it's in the current package · 0e3d5132
      Ian Lynagh authored
      Suppose we import anotherPackage:M, which exports things from
      anotherPackage:Internal. Then GHC will want to read
      anotherPackage:Internal.hi.
      
      However, if we have also SOURCE-imported thisPackage:Internal then
      we don't want GHC to try to read anotherPackage:Internal.hi-boot
      instead.
      
      The mapping that tells us whether a module is SOURCE-imported uses just
      the module name for the key, so we have to check the package ID before
      looking it up.
      
      Fixes #3007.
      0e3d5132
  33. 07 Jul, 2009 1 commit
  34. 01 Jul, 2009 1 commit
  35. 02 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Make record selectors into ordinary functions · 9ffadf21
      simonpj@microsoft.com authored
      This biggish patch addresses Trac #2670.  The main effect is to make
      record selectors into ordinary functions, whose unfoldings appear in
      interface files, in contrast to their previous existence as magic
      "implicit Ids".  This means that the usual machinery of optimisation,
      analysis, and inlining applies to them, which was failing before when
      the selector was somewhat complicated.  (Which it can be when
      strictness annotations, unboxing annotations, and GADTs are involved.)
      
      The change involves the following points
      
      * Changes in Var.lhs to the representation of Var.  Now a LocalId can
        have an IdDetails as well as a GlobalId.  In particular, the
        information that an Id is a record selector is kept in the
        IdDetails.  While compiling the current module, the record selector
        *must* be a LocalId, so that it participates properly in compilation
        (free variables etc).
      
        This led me to change the (hidden) representation of Var, so that there
        is now only one constructor for Id, not two.
      
      * The IdDetails is persisted into interface files, so that an
        importing module can see which Ids are records selectors.
      
      * In TcTyClDecls, we generate the record-selector bindings in renamed,
        but not typechecked form.  In this way, we can get the typechecker
        to add all the types and so on, which is jolly helpful especially
        when GADTs or type families are involved.  Just like derived
        instance declarations.
      
        This is the big new chunk of 180 lines of code (much of which is
        commentary).  A call to the same function, mkAuxBinds, is needed in
        TcInstDcls for associated types.
      
      * The typechecker therefore has to pin the correct IdDetails on to 
        the record selector, when it typechecks it.  There was a neat way
        to do this, by adding a new sort of signature to HsBinds.Sig, namely
        IdSig.  This contains an Id (with the correct Name, Type, and IdDetails);
        the type checker uses it as the binder for the final binding.  This
        worked out rather easily.
      
      * Record selectors are no longer "implicit ids", which entails changes to
           IfaceSyn.ifaceDeclSubBndrs
           HscTypes.implicitTyThings
           TidyPgm.getImplicitBinds
        (These three functions must agree.)
      
      * MkId.mkRecordSelectorId is deleted entirely, some 300+ lines (incl
        comments) of very error prone code.  Happy days.
      
      * A TyCon no longer contains the list of record selectors: 
        algTcSelIds is gone
      
      The renamer is unaffected, including the way that import and export of
      record selectors is handled.
      
      Other small things
      
      * IfaceSyn.ifaceDeclSubBndrs had a fragile test for whether a data
        constructor had a wrapper.  I've replaced that with an explicit flag
        in the interface file. More robust I hope.
      
      * I renamed isIdVar to isId, which touched a few otherwise-unrelated files.
      
      9ffadf21
  36. 30 Oct, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Add (a) CoreM monad, (b) new Annotations feature · 9bcd95ba
      simonpj@microsoft.com authored
      This patch, written by Max Bolingbroke,  does two things
      
      1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
          which is used as the top-level monad for all the Core-to-Core
          transformations (starting at SimplCore).  It supports
             * I/O (for debug printing)
             * Unique supply
             * Statistics gathering
             * Access to the HscEnv, RuleBase, Annotations, Module
          The patch therefore refactors the top "skin" of every Core-to-Core
          pass, but does not change their functionality.
      
      2.  It adds a completely new facility to GHC: Core "annotations".
          The idea is that you can say
             {#- ANN foo (Just "Hello") #-}
          which adds the annotation (Just "Hello") to the top level function
          foo.  These annotations can be looked up in any Core-to-Core pass,
          and are persisted into interface files.  (Hence a Core-to-Core pass
          can also query the annotations of imported things.)  Furthermore,
          a Core-to-Core pass can add new annotations (eg strictness info)
          of its own, which can be queried by importing modules.
      
      The design of the annotation system is somewhat in flux.  It's
      designed to work with the (upcoming) dynamic plug-ins mechanism,
      but is meanwhile independently useful.
      
      Do not merge to 6.10!  
      9bcd95ba