1. 18 Jul, 2014 1 commit
  2. 14 May, 2014 2 commits
  3. 16 Apr, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update Cabal submodule to tip of v1.20 branch · 8992d526
      Herbert Valerio Riedel authored
      This corresponds to the RC of the soon-to-be Cabal 1.20 release
      
      One noteworthy change is the removal of the `--with-ranlib` flag
      requiring a small adaptation in the GHC build system.
      
      Moreover two new licences were added, MPL and BSD2.
      
      Due to https://github.com/haskell/cabal/issues/1622
      
       Cabal-1.20 now
      allows to strip libraries as well, this doesn't work well with
      `ghc-cabal copy` being fed a `":"` strip-command argument which was
      simply ignored in the past. The current code tries to retain this
      semantics as backward compat. However, this needs more investigation as
      I'm not sure if/why the `test_bindist` step doesn't want the libraries
      to be stripped on installation.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      8992d526
  4. 13 Apr, 2014 1 commit
  5. 20 Jan, 2014 1 commit
    • Gergő Érdi's avatar
      Implement pattern synonyms · 4f8369bf
      Gergő Érdi authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      
      The rundown is this:
      
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
      
        * Unidirectional patterns are declared like thus:
      
              pattern P x <- x:_
      
          The synonym 'P' may only occur in a pattern context:
      
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
      
        * Bidirectional patterns are declared like thus:
      
              pattern P x y = [x, y]
      
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
      
              bar :: Int -> [Int]
              bar x = P x 10
      
        * Patterns can't yet have their own type signatures; signatures are inferred.
      
        * Pattern synonyms may not be recursive, c.f. type synonyms.
      
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
      
              module Foo (pattern Bar) where ...
      
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
      
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
      
              pattern P x y <- [x, y]
      
              f (P True True) = True
              f _             = False
      
              g [True, True] = True
              g _            = False
      
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      
      For more information, see the wiki:
      
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation
      
      Reviewed-by: default avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  6. 01 Oct, 2013 1 commit
  7. 18 Sep, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Change role annotation syntax. · f4046b50
      eir@cis.upenn.edu authored
      This fixes bugs #8185, #8234, and #8246. The new syntax is explained
      in the comments to #8185, appears in the "Roles" subsection of the
      manual, and on the [wiki:Roles] wiki page.
      
      This change also removes the ability for a role annotation on type
      synonyms, as noted in #8234.
      f4046b50
  8. 11 Mar, 2013 1 commit
  9. 03 Mar, 2013 1 commit
    • ian@well-typed.com's avatar
      Automatically add the $(exeext) to program names · 2b85372c
      ian@well-typed.com authored
      We now define _PROGNAME, and _PROG is automatically defined with
      $(exeext). This will shortly automatically use the right exeext
      depending on what stage it is being compiled with (exeext may be
      different for different stages when cross-compiling).
      2b85372c
  10. 14 Feb, 2013 1 commit
  11. 18 Oct, 2012 1 commit
  12. 14 Oct, 2012 2 commits
  13. 03 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Build the dynamic way by default on Linux/amd64 · 898cb090
      ian@well-typed.com authored
      This required various build system changes to get the build to go
      through.
      
      In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
      to find their libraries. In the future, we might change the inplace tree
      to be the same shape as an installed tree instead. However, this would
      mean changing the way we do installation, as currently we use cabal's
      installation methods to install the libraries, but that only works if
      the libraries are under libraries/foo/dist-install/build/..., rather
      than in inplace/lib/...
      898cb090
  14. 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
  15. 07 May, 2012 1 commit
  16. 24 Feb, 2012 1 commit
  17. 06 Feb, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor HsDecls again, to put family instances in InstDecl · f92591de
      Simon Peyton Jones authored
      This continues the clean up of the front end.  Since they
      were first invented, type and data family *instance* decls
      have been in the TyClDecl data type, even though they always
      treated separately.
      
      This patch takes a step in the right direction
        * The InstDecl type now includes both class instances and
          type/data family instances
      
        * The hs_tyclds field of HsGroup now never has any family
          instance declarations in it
      
      However a family instance is still a TyClDecl.  It should really
      be a separate type, but that's the next step.
      
      All this was provoked by fixing Trac #5792 in the HEAD.
      (I did a less invasive fix on the branch.)
      f92591de
  18. 01 Oct, 2011 1 commit
  19. 03 Jul, 2011 1 commit
    • Ian Lynagh's avatar
      defaultErrorHandler now only takes LogAction · e01fffc6
      Ian Lynagh authored
      It used to take a whole DynFlags, but that meant we had to
      create a DynFlags with (panic "No settings") for settings, as
      we didn't have any real settings.
      
      Now we just pass the LogAction, which is all that it actually needed.
      The default is exported from DynFlags as defaultLogAction.
      e01fffc6
  20. 09 Jun, 2011 1 commit
  21. 28 May, 2011 1 commit
  22. 04 May, 2011 1 commit
    • dreixel's avatar
      Remove HsNumTy and TypePati. · fed25228
      dreixel authored
      They belonged to the old generic deriving mechanism, so they can go. Adapted a lot of code as a consequence.
      fed25228
  23. 21 Apr, 2011 1 commit
    • Ian Lynagh's avatar
      Initialise Settings before DynFlags · bfa0c2ed
      Ian Lynagh authored
      Stops us having to temporarily have a panic in the DynFlags.
      We still need a panic in the DynFlags used for the top-level
      error handler, though.
      bfa0c2ed
  24. 10 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Do dependency analysis when kind-checking type declarations · 6ea06bbf
      simonpj@microsoft.com authored
      This patch fixes Trac #4875.  The main point is to do dependency
      analysis on type and class declarations, and kind-check them in
      dependency order, so as to improve error messages.
      
      This patch means that a few programs that would typecheck before won't
      typecheck any more; but before we were (naughtily) going beyond
      Haskell 98 without any language-extension flags, and Trac #4875
      convinces me that doing so is a Bad Idea.
      
      Here's an example that won't typecheck any more
             data T a b = MkT (a b)
             type F k = T k Maybe
      
      If you look at T on its own you'd default 'a' to kind *->*;
      and then kind-checking would fail on F.
      
      But GHC currently accepts this program beause it looks at
      the *occurrences* of T.
      6ea06bbf
  25. 12 Nov, 2010 1 commit
  26. 27 Oct, 2010 1 commit
  27. 06 May, 2010 1 commit
  28. 21 Feb, 2010 2 commits
  29. 10 Nov, 2008 1 commit
  30. 28 Oct, 2008 1 commit
  31. 13 Oct, 2008 1 commit
  32. 07 Oct, 2008 1 commit
  33. 06 Nov, 2007 1 commit
  34. 05 Nov, 2007 3 commits
  35. 25 Jun, 2007 1 commit