1. 19 Aug, 2014 1 commit
    • Austin Seipp's avatar
      build: require GHC 7.6 for bootstrapping · 527bcc41
      Austin Seipp authored
      
      
      Summary:
      Per the usual standards, a build of GHC is only compileable
      by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
      we don't get suckered into supporting older compilers, let's remove
      this support now.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan:
      Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
      with 7.6 or better, and everything works.
      
      Reviewers: hvr
      
      Reviewed By: hvr
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D167
      527bcc41
  2. 13 Jul, 2014 1 commit
  3. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  4. 19 Aug, 2013 1 commit
  5. 02 Aug, 2013 1 commit
  6. 31 Jul, 2013 1 commit
    • ian@well-typed.com's avatar
      Add NegativeLiterals extension · ef739635
      ian@well-typed.com authored
      I'd been meaning to do this for some time, but finally got around to it
      due to the overflowing literals warning. With that enabled, we were
      getting a warning for
          -128 :: Int8
      as that is parsed as
          negate (fromInteger 128)
      which just happens to do the right thing, as
          negate (fromInteger 128) = negate (-128) = -128
      ef739635
  7. 30 May, 2013 1 commit
  8. 15 Mar, 2013 1 commit
  9. 02 Oct, 2012 1 commit
  10. 28 Aug, 2012 1 commit
  11. 29 Jun, 2012 1 commit
  12. 22 Jun, 2012 4 commits
  13. 15 May, 2012 1 commit
    • batterseapower's avatar
      Support code generation for unboxed-tuple function arguments · 09987de4
      batterseapower authored
      This is done by a 'unarisation' pre-pass at the STG level which
      translates away all (live) binders binding something of unboxed
      tuple type.
      
      This has the following knock-on effects:
        * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
        * Various relaxed type checks in typechecker, 'foreign import prim' etc
        * All case binders may be live at the Core level
      09987de4
  14. 27 Feb, 2012 1 commit
  15. 14 Jan, 2012 2 commits
  16. 20 Dec, 2011 1 commit
  17. 05 Nov, 2011 1 commit
  18. 04 Nov, 2011 1 commit
  19. 19 Oct, 2011 1 commit
  20. 23 Sep, 2011 1 commit
  21. 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
  22. 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
  23. 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
  24. 22 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      Implement a findCycle function in Digraph, · e8590218
      Simon Peyton Jones authored
      and use it to report module loops nicely
      
      This fixes Trac #5307. Now we get
      
          Module imports form a cycle:
                   module `M8' (.\M8.hs)
                  imports `M1' (M1.hs)
            which imports `M9' (.\M9.hs-boot)
            which imports `M8' (.\M8.hs)
      
      And the algorithm is linear time.
      e8590218
  25. 21 Apr, 2011 1 commit
  26. 08 Apr, 2011 1 commit
    • Simon Marlow's avatar
      Force re-linking if the options have changed (#4451) · 814edf44
      Simon Marlow authored
      A common sequence of commands (at least for me) is this:
      
      $ ghc hello
      1 of 1] Compiling Main             ( hello.hs, hello.o )
      Linking hello ...
      $ ./hello +RTS -s
      hello: Most RTS options are disabled. Link with -rtsopts to enable them.
      $ ghc hello -rtsopts
      $
      
      grr, nothing happened.  I could use -fforce-recomp, but if this was a
      large program I probably don't want to recompile it all again, so:
      
      $ rm hello
      removed `hello'
      $ ghc hello -rtsopts
      Linking hello ...
      $ ./hello +RTS -s
      ./hello +RTS -s
      Hello World!
                51,264 bytes allocated in the heap
                 2,904 bytes copied during GC
                43,808 bytes maximum residency (1 sample(s))
                17,632 bytes maximum slop
      etc.
      
      With this patch, GHC notices when the options have changed and forces
      a relink, so you don't need to rm the binary or use -fforce-recomp.
      This is done by adding the pertinent stuff to the binary in a special
      section called ".debug-ghc-link-info":
      
      $ readelf -p .debug-ghc-link-info ./hello
      String dump of section 'ghc-linker-opts':
        [     0]  (["-lHSbase-4.3.1.0","-lHSinteger-gmp-0.2.0.2","-lgmp","-lHSghc-prim-0.2.0.0","-lHSrts","-lm","-lrt","-ldl","-u","ghczmprim_GHCziTypes_Izh_static_info","-u","ghczmprim_GHCziTypes_Czh_static_info","-u","ghczmprim_GHCziTypes_Fzh_static_info","-u","ghczmprim_GHCziTypes_Dzh_static_info","-u","base_GHCziPtr_Ptr_static_info","-u","base_GHCziWord_Wzh_static_info","-u","base_GHCziInt_I8zh_static_info","-u","base_GHCziInt_I16zh_static_info","-u","base_GHCziInt_I32zh_static_info","-u","base_GHCziInt_I64zh_static_info","-u","base_GHCziWord_W8zh_static_info","-u","base_GHCziWord_W16zh_static_info","-u","base_GHCziWord_W32zh_static_info","-u","base_GHCziWord_W64zh_static_info","-u","base_GHCziStable_StablePtr_static_info","-u","ghczmprim_GHCziTypes_Izh_con_info","-u","ghczmprim_GHCziTypes_Czh_con_info","-u","ghczmprim_GHCziTypes_Fzh_con_info","-u","ghczmprim_GHCziTypes_Dzh_con_info","-u","base_GHCziPtr_Ptr_con_info","-u","base_GHCziPtr_FunPtr_con_info","-u","base_GHCziStable_StablePtr_con_info","-u","ghczmprim_GHCziTypes_False_closure","-u","ghczmprim_GHCziTypes_True_closure","-u","base_GHCziPack_unpackCString_closure","-u","base_GHCziIOziException_stackOverflow_closure","-u","base_GHCziIOziException_heapOverflow_closure","-u","base_ControlziExceptionziBase_nonTermination_closure","-u","base_GHCziIOziException_blockedIndefinitelyOnMVar_closure","-u","base_GHCziIOziException_blockedIndefinitelyOnSTM_closure","-u","base_ControlziExceptionziBase_nestedAtomically_closure","-u","base_GHCziWeak_runFinalizzerBatch_closure","-u","base_GHCziTopHandler_runIO_closure","-u","base_GHCziTopHandler_runNonIO_closure","-u","base_GHCziConcziIO_ensureIOManagerIsRunning_closure","-u","base_GHCziConcziSync_runSparks_closure","-u","base_GHCziConcziSignal_runHandlers_closure","-lHSffi"],Nothing,RtsOptsAll,False,[],[])
      
      And GHC itself uses the readelf command to extract it when deciding
      whether to relink.  The reason for the name ".debug-ghc-link-info" is
      that sections beginning with ".debug" are removed automatically by
      strip.
      
      This currently only works on Linux; Windows and OS X still have the
      old behaviour.
      814edf44
  27. 07 Jan, 2011 1 commit
  28. 22 Dec, 2010 1 commit
  29. 18 Dec, 2010 1 commit
  30. 15 Dec, 2010 1 commit
  31. 10 May, 2010 1 commit
  32. 13 Apr, 2010 1 commit
  33. 30 Mar, 2010 1 commit
  34. 08 Feb, 2010 1 commit
  35. 03 Jan, 2010 1 commit
  36. 04 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Substantial improvements to coercion optimisation · b06d623b
      simonpj@microsoft.com authored
      The main purpose of this patch is to add a bunch of new rules
      to the coercion optimiser.  They are documented in the (revised)
      Appendix of the System FC paper.  
      
      Some code has moved about:
      
      - OptCoercion is now a separate module, mainly because it
        now uses tcMatchTy, which is defined in Unify, so OptCoercion
        must live higehr up in the hierarchy
      
      - Functions that manipulate Kinds has moved from 
        Type.lhs to Coercion.lhs.  Reason: the function typeKind
        now needs to call coercionKind.  And in any case, a Kind is
        a flavour of Type, so it builds on top of Type; indeed Coercions
        and Kinds are both flavours of Type.
      
        This change required fiddling with a number of imports, hence
        the one-line changes to otherwise-unrelated modules
      
      - The representation of CoTyCons in TyCon has changed.   Instead of
        an extensional representation (a kind checker) there is now an
        intensional representation (namely TyCon.CoTyConDesc).  This was
        needed for one of the new coercion optimisations.
      b06d623b