1. 01 Nov, 2012 1 commit
  2. 18 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Refactor the way dump flags are handled · d4a19643
      ian@well-typed.com authored
      We were being inconsistent about how we tested whether dump flags
      were enabled; in particular, sometimes we also checked the verbosity,
      and sometimes we didn't.
      This lead to oddities such as "ghc -v4" printing an "Asm code" section
      which didn't contain any code, and "-v4" enabled some parts of
      "-ddump-deriv" but not others.
      Now all the tests use dopt, which also takes the verbosity into account
      as appropriate.
  3. 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
  4. 16 Sep, 2012 1 commit
  5. 20 Jul, 2012 1 commit
  6. 12 Jun, 2012 1 commit
  7. 07 Jun, 2012 1 commit
  8. 29 May, 2012 1 commit
  9. 15 May, 2012 2 commits
  10. 12 Apr, 2012 1 commit
  11. 11 Apr, 2012 1 commit
  12. 01 Mar, 2012 1 commit
    • Simon Marlow's avatar
      GHCi: add :seti, for options that apply only at the prompt (#3217) · 2e55760b
      Simon Marlow authored
      GHCi now maintains two DynFlags: one that applies to whole modules
      loaded with :load, and one that applies to things typed at the prompt
      (expressions, statements, declarations, commands).
        The :set command modifies both DynFlags.  This is for backwards
        compatibility: users won't notice any difference.
        The :seti command applies only to the interactive DynFlags.
      Additionally, I made a few changes to ":set" (with no arguments):
        * Now it only prints out options that differ from the defaults,
          rather than the whole list.
        * There is a new variant, ":set -a" to print out all options (the
          old behaviour).
        * It also prints out language options.
      Prelude> :set
      options currently set: none.
      base language is: Haskell2010
      with the following modifiers:
      GHCi-specific dynamic flag settings:
      other dynamic, non-language, flag settings:
      warning settings:
      ":seti" (with no arguments) does the same as ":set", but for the
      interactive options.  It also has the "-a" option.
      The interactive DynFlags are kept in the InteractiveContext, and
      copied into the HscEnv at the appropriate points (all in HscMain).
      There are some new GHC API operations:
      -- | Set the 'DynFlags' used to evaluate interactive expressions.
      setInteractiveDynFlags :: GhcMonad m => DynFlags -> m ()
      -- | Get the 'DynFlags' used to evaluate interactive expressions.
      getInteractiveDynFlags :: GhcMonad m => m DynFlags
      -- | Sets the program 'DynFlags'.
      setProgramDynFlags :: GhcMonad m => DynFlags -> m [PackageId]
      -- | Returns the program 'DynFlags'.
      getProgramDynFlags :: GhcMonad m => m DynFlags
      Note I have not completed the whole of the plan outlined in #3217 yet:
      when in the context of a loaded module we don't take the interactive
      DynFlags from that module.  That needs some more refactoring and
      thinking about, because we'll need to save and restore the original
      interactive DynFlags.
      This solves the immediate problem that people are having with the new
      flag checking in 7.4.1, because now it is possible to set language
      options in ~/.ghci that do not affect loaded modules and thereby cause
  13. 14 Feb, 2012 1 commit
  14. 26 Jan, 2012 3 commits
  15. 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.
       * 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.
  16. 20 Dec, 2011 1 commit
  17. 04 Nov, 2011 1 commit
  18. 21 Oct, 2011 1 commit
  19. 18 Oct, 2011 1 commit
  20. 05 Oct, 2011 1 commit
  21. 23 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Implement GHCi command :kind! which normalises its type · f3c7ed72
      Simon Peyton Jones authored
         type family F a
         type instance F Int = Bool
         type instance F Bool = Char
      In GHCi
         *TF> :kind (F Int, F Bool)
         (F Int, F Bool) :: *
         *TF> :kind! F Int
         (F Int, F Bool) :: *
         = (Bool, Char)
      We could call it ":normalise" but it seemed quite nice to have an
      eager version of :kind
  22. 21 Sep, 2011 2 commits
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Add support for all top-level declarations to GHCi · 3db75724
      Simon Marlow authored
        This is work mostly done by Daniel Winograd-Cort during his
        internship at MSR Cambridge, with some further refactoring by me.
      This commit adds support to GHCi for most top-level declarations that
      can be used in Haskell source files.  Class, data, newtype, type,
      instance are all supported, as are Type Family-related declarations.
      The current set of declarations are shown by :show bindings.  As with
      variable bindings, entities bound by newer declarations shadow earlier
      Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
      Documentation to follow.
  23. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
  24. 02 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
        * Used record notation consistently for ImportDecl
  25. 14 Jul, 2011 1 commit
    • Ian Lynagh's avatar
      Separate the warning flags into their own datatype · 493ea4ab
      Ian Lynagh authored
      The -w flag wasn't turning off a few warnings (Opt_WarnMissingImportList,
      Opt_WarnMissingLocalSigs, Opt_WarnIdentities). Rather than just adding
      them, I've separated the Opt_Warn* contructors off into their own type,
      so -w now just sets the list of warning flags to [].
  26. 18 Jun, 2011 2 commits
  27. 03 Jun, 2011 1 commit
  28. 26 Jan, 2011 1 commit
  29. 12 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Major refactoring of the type inference engine · 27310213
      simonpj@microsoft.com authored
      This patch embodies many, many changes to the contraint solver, which
      make it simpler, more robust, and more beautiful.  But it has taken
      me ages to get right. The forcing issue was some obscure programs
      involving recursive dictionaries, but these eventually led to a
      massive refactoring sweep.
      Main changes are:
       * No more "frozen errors" in the monad.  Instead "insoluble
         constraints" are now part of the WantedConstraints type.
       * The WantedConstraint type is a product of bags, instead of (as
         before) a bag of sums.  This eliminates a good deal of tagging and
       * This same WantedConstraints data type is used
           - As the way that constraints are gathered
           - As a field of an implication constraint
           - As both argument and result of solveWanted
           - As the argument to reportUnsolved
       * We do not generate any evidence for Derived constraints. They are
         purely there to allow "impovement" by unifying unification
       * In consequence, nothing is ever *rewritten* by a Derived
         constraint.  This removes, by construction, all the horrible
         potential recursive-dictionary loops that were making us tear our
         hair out.  No more isGoodRecEv search either. Hurrah!
       * We add the superclass Derived constraints during canonicalisation,
         after checking for duplicates.  So fewer superclass constraints
         are generated than before.
       * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
         SkolemInfo lives in the GivenLoc of the Implication, where it
         can be tidied, zonked, and substituted nicely.  This alone is
         a major improvement.
       * Tidying is improved, so that we tend to get t1, t2, t3, rather
         than t1, t11, t111, etc
         Moreover, unification variables are always printed with a digit
         (thus a0, a1, etc), so that plain 'a' is available for a skolem
         arising from a type signature etc. In this way,
           (a) We quietly say which variables are unification variables,
               for those who know and care
           (b) Types tend to get printed as the user expects.  If he writes
                   f :: a -> a
                   f = ...blah...
               then types involving 'a' get printed with 'a', rather than
               some tidied variant.
       * There are significant improvements in error messages, notably
         in the "Cannot deduce X from Y" messages.
  30. 26 Feb, 2011 1 commit
    • vivian's avatar
      :script file scripts in GHCi #1363 · eccb2d89
      vivian authored
      This patch adds the script command in GHCi
      A file is read and executed as a series of GHCi commands.
      Execution terminates on the first error.  The filename and
      line number are included in the error.
  31. 21 Nov, 2010 1 commit
  32. 15 Nov, 2010 1 commit
    • pepeiborra@gmail.com's avatar
      Fix bug #3165 (:history throws irrefutable pattern failed) · add9b7f1
      pepeiborra@gmail.com authored
      I ran across this bug and took the time to fix it, closing
      a long time due TODO in InteractiveEval.hs
      Instead of looking around to find the enclosing declaration
      of a tick, this patch makes use of the information already collected during the
      coverage desugaring phase
  33. 27 Oct, 2010 1 commit
    • Simon Marlow's avatar
      Refactoring and tidyup of HscMain and related things (also fix #1666) · 94bf0d36
      Simon Marlow authored
      While trying to fix #1666 (-Werror aborts too early) I decided to some
      tidyup in GHC/DriverPipeline/HscMain.
       - The GhcMonad overloading is gone from DriverPipeline and HscMain
         now.  GhcMonad is now defined in a module of its own, and only
         used in the top-level GHC layer.  DriverPipeline and HscMain
         use the plain IO monad and take HscEnv as an argument.
       - WarnLogMonad is gone.  printExceptionAndWarnings is now called
         printException (the old name is deprecated).  Session no longer
         contains warnings.
       - HscMain has its own little monad that collects warnings, and also
         plumbs HscEnv around.  The idea here is that warnings are collected
         while we're in HscMain, but on exit from HscMain (any function) we
         check for warnings and either print them (via log_action, so IDEs
         can still override the printing), or turn them into an error if
         -Werror is on.
       - GhcApiCallbacks is gone, along with GHC.loadWithLogger.  Thomas
         Schilling told me he wasn't using these, and I don't see a good
         reason to have them.
       - there's a new pure API to the parser (suggestion from Neil Mitchell):
            parser :: String
                   -> DynFlags
                   -> FilePath
                   -> Either ErrorMessages (WarningMessages, 
                                            Located (HsModule RdrName))
  34. 19 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Clean up the debugger code · a40f2735
      simonpj@microsoft.com authored
      In particular there is much less fiddly skolemisation now
      Things are not *quite* right (break001 and 006 still fail), 
      but they are *much* better than before.
  35. 15 Oct, 2010 1 commit
    • Ian Lynagh's avatar
      Add a -fghci-sandbox flag so that we can en/disable the ghci sandbox · bf60bbfb
      Ian Lynagh authored
      It's on by default (which matches the previous behaviour).
      GLUT on OS X needs to run on the main thread. If you
      try to use it from another thread then you just get a
      white rectangle rendered. For this, or anything else
      with such restrictions, you can turn the GHCi sandbox off
      and things will be run in the main thread.