1. 17 Nov, 2015 2 commits
  2. 14 Nov, 2015 1 commit
  3. 01 Nov, 2015 1 commit
  4. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  5. 23 Sep, 2015 1 commit
  6. 22 Sep, 2015 1 commit
  7. 17 Sep, 2015 1 commit
  8. 27 Jul, 2015 1 commit
    • Adam Sandberg Eriksson's avatar
      Implementation of StrictData language extension · f842ad6c
      Adam Sandberg Eriksson authored
      This implements the `StrictData` language extension, which lets the
      programmer default to strict data fields in datatype declarations on a
      per-module basis.
      
      Specification and motivation can be found at
      https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
      
      This includes a tricky parser change due to conflicts regarding `~` in
      the type level syntax: all ~'s are parsed as strictness annotations (see
      `strict_mark` in Parser.y) and then turned into equality constraints at
      the appropriate places using `RdrHsSyn.splitTilde`.
      
      Updates haddock submodule.
      
      Test Plan: Validate through Harbormaster.
      
      Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari
      
      Reviewed By: simonpj, tibbe, bgamari
      
      Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1033
      
      GHC Trac Issues: #8347
      f842ad6c
  9. 03 Jan, 2015 1 commit
  10. 23 Dec, 2014 1 commit
  11. 18 Dec, 2014 1 commit
  12. 10 Dec, 2014 1 commit
  13. 28 Nov, 2014 1 commit
  14. 21 Nov, 2014 2 commits
    • Lennart Kolmodin's avatar
      ghc: allow --show-options and --interactive together · 624a7c5a
      Lennart Kolmodin authored
      Summary:
      Previously 'ghc --show-options' showed all options that GHC can possibly
      accept. With this patch, it'll only show the options that have effect in
      non-interactive modes.
      This change also adds support for using 'ghc --interactive --show-options'
      which previously was disallowed. This command will show all options that have
      effect in the interactive mode.
      The CmdLineParser is updated to know about the GHC modes, and then each flag
      is annotated with which mode it has effect.
      This fixes #9259.
      
      Test Plan:
      Try out --show-options with --interactive on the command line. With and without
      --interactive should give different results.
      Run the test suite, mode001 has been updated to verify this new flag
      combination.
      
      Reviewers: austin, jstolarek
      
      Reviewed By: austin, jstolarek
      
      Subscribers: jstolarek, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D337
      
      GHC Trac Issues: #9259
      624a7c5a
    • jpm@cs.ox.ac.uk's avatar
      Implement #5462 (deriving clause for arbitrary classes) · 7ed482d9
      jpm@cs.ox.ac.uk authored
      Summary: (this has been submitted on behalf on @dreixel)
      
      Reviewers: simonpj, hvr, austin
      
      Reviewed By: simonpj, austin
      
      Subscribers: goldfire, thomie, carter, dreixel
      
      Differential Revision: https://phabricator.haskell.org/D476
      
      GHC Trac Issues: #5462
      7ed482d9
  15. 29 Jun, 2014 1 commit
  16. 27 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add -XBinaryLiterals language extension (re #9224) · 1c0b5fdc
      Herbert Valerio Riedel authored
      Haskell2010 supports
      
      - base-10 (prefix-less),
      - base-8 (via `0[oO]`-prefix), and
      - base-16 (via `0[xX]`-prefix) integer literals.
      
      This commit adds syntax support for base-2 integer literals via the new `0[bB]`
      prefix. The use of a `0b` prefix for indicating binary literals is known
      from popular programming languages such as C++14, Perl, Python, Ruby, and Java.
      
      This syntax extension is disabled by default and can be enabled via the
      new `{-# LANGUAGE BinaryLiterals #-}` pragma and/or the new `-XBinaryLiterals`
      
      This new extensions requires to upgrade the `ExtsBitmap` type from
      `Word` to `Word64` as this adds a 33th flag which is not guaranteed to
      fit into a `Word`.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      
      Differential Revision: https://phabricator.haskell.org/D22
      1c0b5fdc
  17. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus 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/ImplementationReviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      4f8369bf
  18. 15 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Turn -XTypeHoles into a (on by default) warning · 235fd88a
      Austin Seipp authored
      After some discussion on ghc-devs@ and elsewhere, it seemed favorable to
      make this change as type holes don't let any invalid programs though,
      they merely change what the compiler reports in case of certain errors
      (namely unbound occurrences, or _ appearing on a LHS.)
      
      Now, the warning mechanism is controlled by -f[no-]warn-type-errors,
      just like any other regular warning. Again, on by default.
      
      The documentation and tests have been updated accordingly.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      235fd88a
  19. 06 Sep, 2013 1 commit
  20. 04 Sep, 2013 1 commit
  21. 29 Aug, 2013 1 commit
  22. 31 Jul, 2013 1 commit
  23. 13 Mar, 2013 1 commit
  24. 14 Feb, 2013 1 commit
  25. 12 Feb, 2013 1 commit
    • jpm@cs.ox.ac.uk's avatar
      Implement poly-kinded Typeable · 94d8b995
      jpm@cs.ox.ac.uk authored
      This patch makes the Data.Typeable.Typeable class work with arguments of any
      kind. In particular, this removes the Typeable1..7 class hierarchy, greatly
      simplyfing the whole Typeable story. Also added is the AutoDeriveTypeable
      language extension, which will automatically derive Typeable for all types and
      classes declared in that module. Since there is now no good reason to give
      handwritten instances of the Typeable class, those are ignored (for backwards
      compatibility), and a warning is emitted.
      
      The old, kind-* Typeable class is now called OldTypeable, and lives in the
      Data.OldTypeable module. It is deprecated, and should be removed in some future
      version of GHC.
      94d8b995
  26. 08 Jan, 2013 2 commits
  27. 04 Jan, 2013 1 commit
  28. 25 Oct, 2012 1 commit
  29. 28 Sep, 2012 1 commit
  30. 16 Jul, 2012 1 commit
  31. 25 Mar, 2012 1 commit
  32. 16 Jan, 2012 1 commit
  33. 13 Dec, 2011 1 commit
  34. 28 Nov, 2011 1 commit
  35. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 5e1333af
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      
      For more information, see http://haskell.org/haskellwiki/GHC/Kinds
      5e1333af
  36. 18 Oct, 2011 1 commit
  37. 26 Sep, 2011 1 commit