1. 21 Jul, 2016 6 commits
    • Ömer Sinan Ağacan's avatar
      Fix and document Unique generation for sum TyCon and DataCons · 8265c783
      Ömer Sinan Ağacan authored
      Test Plan: validate
      
      Reviewers: bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2420
      8265c783
    • Ömer Sinan Ağacan's avatar
      Bump Haddock submodule · 6a4dc891
      Ömer Sinan Ağacan authored
      6a4dc891
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      9c54185b
    • Simon Peyton Jones's avatar
      Comments only · a09c0e3e
      Simon Peyton Jones authored
      a09c0e3e
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      Summary:
      This patch implements primitive unboxed sum types, as described in
      https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
      
      Main changes are:
      
      - Add new syntax for unboxed sums types, terms and patterns. Hidden
        behind `-XUnboxedSums`.
      
      - Add unlifted unboxed sum type constructors and data constructors,
        extend type and pattern checkers and desugarer.
      
      - Add new RuntimeRep for unboxed sums.
      
      - Extend unarise pass to translate unboxed sums to unboxed tuples right
        before code generation.
      
      - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
        code generation when sum values are involved.
      
      - Add user manual section for unboxed sums.
      
      Some other changes:
      
      - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
        `MultiValAlt` to be able to use those with both sums and tuples.
      
      - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
        wrong, given an `Any` `TyCon`, there's no way to tell what its kind
        is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
      
      - Fix some bugs on the way: #12375.
      
      Not included in this patch:
      
      - Update Haddock for new the new unboxed sum syntax.
      
      - `TemplateHaskell` support is left as future work.
      
      For reviewers:
      
      - Front-end code is mostly trivial and adapted from unboxed tuple code
        for type checking, pattern checking, renaming, desugaring etc.
      
      - Main translation routines are in `RepType` and `UnariseStg`.
        Documentation in `UnariseStg` should be enough for understanding
        what's going on.
      
      Credits:
      
      - Johan Tibell wrote the initial front-end and interface file
        extensions.
      
      - Simon Peyton Jones reviewed this patch many times, wrote some code,
        and helped with debugging.
      
      Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
                 simonmar, hvr, erikd
      
      Reviewed By: simonpj
      
      Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
                   thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2259
      714bebff
  2. 20 Jul, 2016 13 commits
    • Ben Gamari's avatar
      Revert "Clean up interaction between name cache and built-in syntax" · 83e4f495
      Ben Gamari authored
      This reverts commit 9513fe6b.
      
      Sadly this broke with -DDEBUG.
      83e4f495
    • gcampax's avatar
      Compact Regions · cf989ffe
      gcampax authored
      This brings in initial support for compact regions, as described in the
      ICFP 2015 paper "Efficient Communication and Collection with Compact
      Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni
      Campagna.
      
      Some things may change before the 8.2 release, but I (Simon M.) wanted
      to get the main patch committed so that we can iterate.
      
      What documentation there is is in the Data.Compact module in the new
      compact package.  We'll need to extend and polish the documentation
      before the release.
      
      Test Plan:
      validate
      (new test cases included)
      
      Reviewers: ezyang, simonmar, hvr, bgamari, austin
      
      Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1264
      
      GHC Trac Issues: #11493
      cf989ffe
    • Ben Gamari's avatar
      Add another testcase for #12082 · 93acc02f
      Ben Gamari authored
      Test Plan: Validate, should pass.
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2399
      
      GHC Trac Issues: #12082
      93acc02f
    • Ben Gamari's avatar
      testsuite: Add regression test for #12381 · a4f2b766
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2408
      
      GHC Trac Issues: #12381, #11348
      a4f2b766
    • Ben Gamari's avatar
      Clean up interaction between name cache and built-in syntax · 9513fe6b
      Ben Gamari authored
      This cleans up various aspects of the handling of built-in syntax in the
      original name cache (hopefully resulting in a nice reduction in compiler
      allocations),
      
        * Remove tuple types from original name cache: There is really no
          reason for these to be in the name cache since we already handle
          them specially in interface files to ensure that we can resolve them
          directly to Names, avoiding extraneous name cache lookups.
      
        * Sadly it's not possible to remove all traces of tuples from the
          name cache, however. Namely we need to keep the tuple type
          representations in since otherwise they would need to be wired-in
      
        * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe
          and rename it to isTupleOcc_maybe
      
        * Split lookupOrigNameCache into two variants,
      
           * lookupOrigNameCache': Merely looks up an OccName in the original
             name cache, making no attempt to resolve tuples
      
           * lookupOrigNameCache: Like the above but handles tuples as well.
             This is given the un-primed name since it does the "obvious"
             thing from the perspective of an API user, who knows nothing of
             our special treatment of tuples.
      
      Arriving at this design took a significant amount of iteration. The
      trail of debris leading here can be found in #11357.
      
      Thanks to ezyang and Simon for all of their help in coming to this
      solution.
      
      Test Plan: Validate
      
      Reviewers: goldfire, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2414
      
      GHC Trac Issues: #11357
      9513fe6b
    • Ben Gamari's avatar
      InstEnv: Ensure that instance visibility check is lazy · ed480981
      Ben Gamari authored
      Previously instIsVisible had completely broken the laziness of
      lookupInstEnv' since it would examine is_dfun_name to check the name of
      the defining module (to know whether it is an interactive module). This
      resulted in the visibility check drawing in an interface file
      unnecessarily. This contributed to the unnecessary regression in
      compiler allocations reported in #12367.
      
      Test Plan: Validate, check nofib changes
      
      Reviewers: simonpj, ezyang, austin
      
      Reviewed By: ezyang
      
      Subscribers: thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2411
      
      GHC Trac Issues: #12367
      ed480981
    • thomasw's avatar
      Update docs for partial type signatures (#12365) · 627c767b
      thomasw authored
      * Update the sample error messages. The messages have been reworded and
        reformatted since GHC 7.10.
      
      * Mention `TypeApplications` in "Where can they occur?"
      
      * The name of a named wild card is no longer used in the name of a
        resulting type variable. Before: `_foo` => `w_foo`, now: `_foo` => `t`
        or `a`.
      
      Test Plan: generate the users guide
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2413
      
      GHC Trac Issues: #12365
      627c767b
    • Dylan Meysmans's avatar
      Data.Either: Add fromLeft and fromRight (#12402) · a0f83a62
      Dylan Meysmans authored
      Reviewers: austin, hvr, RyanGlScott, bgamari
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2403
      
      GHC Trac Issues: #12402
      a0f83a62
    • Moritz Angermann's avatar
      Cleanup PosixSource.h · cac3fb06
      Moritz Angermann authored
      When trying to build arm64-apple-iso, the build fell over
      `strdup`, as the arm64-apple-ios build did not fall into `darwin_HOST_OS`,
      and would need `ios_HOST_OS`.
      
      This diff tries to clean up PosixSource.h, instead of layering another
      define on top.
      
      As we use `strnlen` in sources that include PosixSource.h, and `strnlen`
      is defined in POSIX.1-2008, the `_POSIX_C_SOURCE` and `_XOPEN_SOURCE`
      are increased accordingly.
      
      Furthermore the `_DARWIN_C_SOURCE` (required for `u_char`, etc. used in
      sysctl.h) define is moved into `OSThreads.h` alongside a similar ifdef
      for freebsd.
      
      Test Plan: Build on all supported platforms.
      
      Reviewers: rwbarton, erikd, austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2375
      cac3fb06
    • seraphime's avatar
      Fix bytecode generator panic · 8de6e13f
      seraphime authored
      This fixes #12128.
      
      The bug was introduced in 1c9fd3f1.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, hvr, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2374
      
      GHC Trac Issues: #12128
      8de6e13f
    • Ben Gamari's avatar
      TcInteract: Add braces to matchClassInst trace output · 908f8e23
      Ben Gamari authored
      This allows you to easily move to the result in a well-equipped editor.
      908f8e23
    • Ryan Scott's avatar
      Make Data.{Bifoldable,Bitraversable} -XSafe · e46b7681
      Ryan Scott authored
      Test Plan:
      Previously, `Data.{Bifoldable,Bitraversable}` were being inferred as
      `Unsafe` due to a transitive `Data.Coerce` import from `Data.Functor.Utils`.
      This rectifies this unfortunate mistake.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, phadej
      
      Differential Revision: https://phabricator.haskell.org/D2412
      e46b7681
    • Ömer Sinan Ağacan's avatar
      Support SCC pragmas in declaration context · 98b2c508
      Ömer Sinan Ağacan authored
      Not having SCCs at the top level is becoming annoying real quick. For
      simplest cases, it's possible to do this transformation:
      
          f x y = ...
          =>
          f = {-# SCC f #-} \x y -> ...
      
      However, it doesn't work when there's a `where` clause:
      
          f x y = <t is in scope>
            where t = ...
          =>
          f = {-# SCC f #-} \x y -> <t is out of scope>
            where t = ...
      
      Or when we have a "equation style" definition:
      
          f (C1 ...) = ...
          f (C2 ...) = ...
          f (C3 ...) = ...
          ...
      
      (usual solution is to rename `f` to `f'` and define a new `f` with a
      `SCC`)
      
      This patch implements support for SCC annotations in declaration
      contexts. This is now a valid program:
      
          f x y = ...
            where
              g z = ...
              {-# SCC g #-}
          {-# SCC f #-}
      
      Test Plan: This passes slow validate (no new failures added).
      
      Reviewers: goldfire, mpickering, austin, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: simonmar, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2407
      98b2c508
  3. 19 Jul, 2016 1 commit
  4. 18 Jul, 2016 4 commits
    • Ryan Scott's avatar
      Make okConIdOcc recognize unboxed tuples · 1fc41d32
      Ryan Scott authored
      Summary:
      `okConIdOcc`, which validates that a type or constructor name is valid
      for splicing using Template Haskell, has a special case for tuples, but
      neglects to look for unboxed tuples, causing some sensible Template Haskell
      code involving unboxed tuples to be rejected.
      
      Fixes #12407.
      
      Test Plan: make test TEST=T12407
      
      Reviewers: austin, bgamari, hvr, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2410
      
      GHC Trac Issues: #12407
      1fc41d32
    • Ryan Scott's avatar
      Fix Template Haskell reification of unboxed tuple types · 514c4a47
      Ryan Scott authored
      Summary:
      Previously, Template Haskell reified unboxed tuple types as boxed
      tuples with twice the appropriate arity.
      
      Fixes #12403.
      
      Test Plan: make test TEST=T12403
      
      Reviewers: hvr, goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2405
      
      GHC Trac Issues: #12403
      514c4a47
    • Ryan Scott's avatar
      Make DeriveFunctor work with unboxed tuples · 3fa3fe8a
      Ryan Scott authored
      Summary:
      Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was
      mistaking for actual data constructor arguments. As a result, a derived
      `Functor` instance for a datatype that contained an unboxed tuple would
      generate twice as many arguments as it needed for an unboxed tuple pattern
      match or expression. The solution is to simply put `dropRuntimeRepArgs` in the
      right place.
      
      Fixes #12399.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, osa1
      
      Differential Revision: https://phabricator.haskell.org/D2404
      
      GHC Trac Issues: #12399
      3fa3fe8a
    • Ryan Scott's avatar
      Fix misspellings of the word "instance" in comments · d213ab3f
      Ryan Scott authored
      [ci skip]
      d213ab3f
  5. 16 Jul, 2016 7 commits
  6. 15 Jul, 2016 1 commit
  7. 14 Jul, 2016 2 commits
  8. 13 Jul, 2016 1 commit
  9. 12 Jul, 2016 1 commit
    • Joachim Breitner's avatar
      Demand analyser: Implement LetUp rule (#12370) · 45d8f4eb
      Joachim Breitner authored
      This makes the implementation match the description in the paper more
      closely: There, a let binding that is not a function has first its body
      analised, and then the binding’s RHS. This way, the demand on the bound
      variable by the body can be fed into the RHS, yielding more precise
      results.
      
      Performance measurements do unfortunately not show significant
      improvements or regessions.
      
      Differential Revision: https://phabricator.haskell.org/D2395
      45d8f4eb
  10. 11 Jul, 2016 2 commits
  11. 10 Jul, 2016 2 commits
    • Alan Zimmerman's avatar
      check-api-annotations utility loads by filename · 9a3df1f8
      Alan Zimmerman authored
      Previously it loaded by modulename, which prevented loading files with a
      Main module.
      9a3df1f8
    • Ben Gamari's avatar
      TysWiredIn: Use UniqFM lookup for built-in OccNames · f53d761d
      Ben Gamari authored
      Previously we would unpack the OccName into a String, then pattern match
      against this string. Due to the implementation of `unpackFS`, this
      actually unpacks the entire contents, even though we often only need to
      look at the first few characters.
      
      Here we take another approach: build a UniqFM with the known built-in
      OccNames, allowing us to use `FastString`'s hash-based comparison
      instead.
      
      Reviewers: simonpj, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2385
      
      GHC Trac Issues: #12357
      f53d761d