1. 18 Oct, 2011 1 commit
    • Ian Lynagh's avatar
      Remove OSUnknown · f75f26cc
      Ian Lynagh authored
      It doesn't make sense. If platformOS is OSUnknown then we don't know the
      answer to any questions about the OS. So now if we don't recognise the
      OS we just fail, and the new OS will need to be added to the datatype.
      f75f26cc
  2. 02 Oct, 2011 1 commit
  3. 29 Sep, 2011 1 commit
  4. 27 Sep, 2011 1 commit
  5. 23 Sep, 2011 1 commit
  6. 21 Sep, 2011 1 commit
    • 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
      ones.
      
      Tests are in testsuite/tests/ghci/scripts/ghci039--ghci054.
      Documentation to follow.
      3db75724
  7. 17 Sep, 2011 1 commit
  8. 09 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement associated type defaults · de8c8d68
      batterseapower authored
      Basically, now you can write:
      
        class Cls a where
          type Typ a
          type Typ a = Just a
      
      And now if an instance does not specify an explicit associated type
      instance, one will be generated afresh based on that default. So for
      example this instance:
      
        instance Cls Int where
      
      Will be equivalent to this one:
      
        instance Cls Int where
          type Typ Int = Just Int
      de8c8d68
  9. 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)
      9729fe7c
  10. 25 Aug, 2011 2 commits
  11. 21 Aug, 2011 1 commit
    • kgardas's avatar
      enhance ArchARM with ISA and ISA extensions · bab9a72d
      kgardas authored
      This patch enhances ArchARM with ARM ISA and ISA extensions details
      as is suggested in the comment in Platform.hs file. The patch is needed
      by future patch which will use ARM ISA information in order to pass
      appropriate command-line option to the LLVM llc tool.
      bab9a72d
  12. 07 Aug, 2011 1 commit
  13. 02 Aug, 2011 1 commit
  14. 29 Jul, 2011 1 commit
    • batterseapower's avatar
      Add CoreMonad.reinitializeGlobals so plugins can work around linker issues · 0e765db4
      batterseapower authored
      When a plugin is loaded, it currently gets linked against a *newly loaded* copy
      of the GHC package. This would not be a problem, except that the new copy has its
      own mutable state that is not shared with that state that has already been initialized by
      the original GHC package.
      
      This leads to loaded plugins calling GHC code which pokes the static flags,
      and then dying with a panic because the static flags *it* sees are uninitialized.
      
      There are two possible solutions:
        1. Export the symbols from the GHC executable from the GHC library and link
           against this existing copy rather than a new copy of the GHC library
        2. Carefully ensure that the global state in the two copies of the GHC
           library matches
      
      I tried 1. and it *almost* works (and speeds up plugin load times!) except
      on Windows. On Windows the GHC library tends to export more than 65536 symbols
      (see #5292) which overflows the limit of what we can export from the EXE and
      causes breakage.
      
      (Note that if the GHC exeecutable was dynamically linked this wouldn't be a problem,
      because we could share the GHC library it links to.)
      
      We are going to try 2. instead. Unfortunately, this means that every plugin
      will have to say `reinitializeGlobals` before it does anything, but never mind.
      
      I've threaded the cr_globals through CoreM rather than giving them as an
      argument to the plugin function so that we can turn this function into
      (return ()) without breaking any plugins when we eventually get 1. working.
      0e765db4
  15. 28 Jul, 2011 1 commit
  16. 27 Jul, 2011 1 commit
  17. 22 Jul, 2011 3 commits
  18. 15 Jul, 2011 1 commit
    • Ian Lynagh's avatar
      More work towards cross-compilation · f07af788
      Ian Lynagh authored
      There's now a variant of the Outputable class that knows what
      platform we're targetting:
      
      class PlatformOutputable a where
          pprPlatform :: Platform -> a -> SDoc
          pprPlatformPrec :: Platform -> Rational -> a -> SDoc
      
      and various instances have had to be converted to use that class,
      and we pass Platform around accordingly.
      f07af788
  19. 12 Jul, 2011 4 commits
  20. 29 Jun, 2011 1 commit
  21. 27 Jun, 2011 1 commit
  22. 18 Jun, 2011 8 commits
  23. 08 Jun, 2011 4 commits
  24. 31 May, 2011 1 commit