GitLab

Summary:
The `Data.OldList` module was originally created in
3daf0023 to provide a way to access the
original list-specialised functions from `Data.List`. It was also made
an exposed module in order to facilitate adapting the
`haskell2010`/`haskell98` packages. However, since the
`haskell2010`/`haskell98` packages were dropped, we no longer need to
expose `Data.OldList`.

Depends on D511

Reviewers: ekmett, austin

Reviewed By: ekmett, austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D513

Summary:
Depends on D510. This is the final blow and removes them from
the tree completely.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: I looked really hard but didn't see them.

Reviewers: hvr, ekmett

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D511

GHC Trac Issues: #9590

This includes a submodule update for `array`.
There is also an added test in libraries/array/tests/T9220.

Alas `{-# LANGUAGE Safe #-}` can't be used since `Data.Coerce` isn't "safe".
However, we use `coerce` just as an optimisation
(see also 4ba884bd which broke the
safe-inferred status of `Data.Functor.Identity`), so this module at least
deserves `{-# LANGUAGE Trustworthy #-}`.

NOTE: `Data.Functor.Identity` was added to `base` in the context of #9664

Reviewed By: luite

Differential Revision: https://phabricator.haskell.org/D507

this impliments #9703 from ghc trac

Test Plan: still needs tests

Reviewers: cmsaperstein, ekmett, goldfire, austin

Reviewed By: goldfire, austin

Subscribers: goldfire, thomie, carter, simonmar

Differential Revision: https://phabricator.haskell.org/D353

GHC Trac Issues: #9703

Summary: This adds a few missing instances that can be automatically derived

Reviewers: hvr, goldfire, austin

Reviewed By: goldfire, austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D495

Test Plan: ./validate

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D492

Summary:
To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with
ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5d). This
solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient
for empty paths").

This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and
adresses (#2521) by testing for a trailing search path separators explicitly
(instead of implicitly using empty search path elements).

Empty paths are now allowed (ignored on Windows, interpreted as current
directory on Posix systems), and trailing path separator still tack on the
user and system package databases.

Also update submodule filepath, which has a version of splitSearchPath which
handles quotes in the same way as our custom version did.

Test Plan:
$ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list
...
db stack: ["/",".","/home","<userdb>","<systemdb>"]
...

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, carter, simonmar

Differential Revision: https://phabricator.haskell.org/D414

GHC Trac Issues: #2521, #9698

This also overrides all optional `Foldable` methods
(which would otherwise be default-implemented in terms of `foldMap`)
with supposedly optimally minimal implementations.

While at it, this also removes the redundant `{-# LANGUAGE CPP #-}`.

Reviewed By: austin, dfeuer

Differential Revision: https://phabricator.haskell.org/D467

The import/export operations were available in `integer-gmp-0.5.1`
already, but need to be reimplemented from scratch for the
`integer-gmp-1.0.0` rewrite.

This also adds a few more operations than were previously available for
use w/ the `BigNat` type (which will be useful for implementing
serialisation for the upcoming `Natural` type)

Specifically, the following operations are (re)added (albeit with
slightly different type-signatures):

 - `sizeInBaseBigNat`
 - `sizeInBaseInteger`
 - `sizeInBaseWord#`

 - `exportBigNatToAddr`
 - `exportIntegerToAddr`
 - `exportWordToAddr`
 - `exportBigNatToMutableByteArray`
 - `exportIntegerToMutableByteArray`
 - `exportWordToMutableByteArray`

 - `importBigNatFromAddr`
 - `importIntegerFromAddr`
 - `importBigNatFromByteArray`
 - `importIntegerFromByteArray`

NOTE: The `integerGmpInternals` test-case is updated but not yet
      re-enabled as it contains tests for other primitives which aren't
      yet reimplemented.

This addresses #9281

Reviewed By: austin, duncan

Differential Revision: https://phabricator.haskell.org/D480

This broke validate due to name shadowing warnings.

This reverts commit 1f6b1ab4.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed-by: Edward Kmett <ekmett@gmail.com>
Authored-by: Yalas, Scott Turner
Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary: Instead, describe what it actually does.

Reviewers: austin, ekmett, simonpj, hvr

Reviewed By: austin, ekmett

Subscribers: simonpj, thomie, carter

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D448

Summary: Make listArray fuse with a list producer. Note: if code size increases too much, we can fix that with some `RULES`.

Reviewers: nomeata, hvr, austin, ekmett, simonmar, bgamari

Reviewed By: bgamari

Subscribers: bgamari, thomie, carter

Differential Revision: https://phabricator.haskell.org/D474

GHC Trac Issues: #9801

Summary:
It describes a work around Trac #3838, but it is already fixed and the
workaround removed, Trac #7653

Test Plan: not needed

Reviewers: hvr, Mikolaj, austin

Reviewed By: austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D478

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D481

GHC Trac Issues: #4900

At optimization level `-O0` `wordToInteger` wasn't inlined, and this caused a
`__integer` literal to turn up in final Core, which would trigger the GHC panic

  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 7.9.20141114 for x86_64-unknown-linux):
	Can't use Integer in integer-*

By forcing inlining via `inline` this is avoided.
This should hopefully address #9800.

This pulls in the new `Generic`-based `-XDefaultSignature`-based default
implementation for `rnf`[1], and will be interesting to use in combination
with the soon to be merged `-XDeriveAnyClass` extension.

This requires updating several other submodules as well in order
to relax the upper bound on `deepseq` and/or in a few cases to
avoid relying on the default method implementation of `rnf`:

 - `Cabal`
 - `bytestring`
 - `containers`
 - `parallel`
 - `process`
 - `time`

 [1]: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/23031

Summary:
Instead of recording exposed-modules and reexported-modules as seperate
fields in the installed package database, this commit merges them into
a single field (exposed-modules).  The motivation for this change is
in preparation for the inclusion of *signatures* into the installed
package database, which may also be reexported.  Merging the representation
means that we can treat reexports uniformly, no matter if they're a normal
module or a signature.

This commit adds a stub for signatures, but that code isn't wired up to
anything yet.

Contains Cabal submodule update to accommodate these changes.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, duncan, austin

Subscribers: thomie, carter, simonmar

Differential Revision: https://phabricator.haskell.org/D421

Implement an `amap`/`coerce` rule in `GHC.Arr` to match the
`map`/`coerce` rule in GHC.Base.

In order to do so, delay inlining `amap` until phase 1.

To prevent the inlining delay from causing major inefficiencies due to
missed list fusion, rewrite `amap` to avoid relying on list fusion. This
has the extra benefit of reducing the size of the compiled amap code by
skipping the impossible case of an array with a negative size.

Reviewed By: nomeata

Differential Revision: https://phabricator.haskell.org/D471

GMP 4.x didn't provide the `mp_bitcnt_t` typedef yet, so we locally
define one if GMP 4.x is detected.

Previously, `Array`s were simply converted to lists, and the list
methods used. That works acceptably well for `foldr` and `foldr1`, but
not so sensibly for most other things. Left folds ended up "twisted" the
way they are for lists, leading to surprising performance
characteristics.

Moreover, this implements `length` and `null` so they check the array
size directly.

Finally, a test is added to the testsuite ensuring the overridden
`Foldable` methods agree with their expected default semantics.

Addresses #9763

Reviewed By: hvr, austin

Differential Revision: https://phabricator.haskell.org/D459

This avoids duplication in `GHC.Base`; originally, we had

  mapM f = sequence . map f

This led to excessive allocation in `cryptarithm2`. Defining

  sequence = mapM id

does not appear to cause any `nofib` problems.

Reviewed By: hvr

Differential Revision: https://phabricator.haskell.org/D470

Make `words` a good producer and `unwords` a good consumer for list
fusion. Thus `unwords . words` will avoid producing an intermediate list
of words, although it will produce each individual word.

Make `unwords` slightly lazier, so that
`unwords (s : undefined) = s ++ undefined` instead of `= undefined`.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D375

Make the comment on the map/coerce rule refer to the right section in
the paper; give the full name of the papers, and name its authors.

[skip ci]

Differential Revision: https://phabricator.haskell.org/D472

Update submodule haskell2010, haskell98, hoop, hpc and stm to fix new
warnings.

This reverts commit f0fcc41d.

New changes: now works on 32-bit platforms too.  I added some basic
support for 64-bit subtraction and comparison operations to the x86
NCG.

This is done as a separate `integer-gmp2` backend library because it
turned out to become a complete rewrite from scratch.

Due to the different (over)allocation scheme and potentially different
accounting (via the new `{shrink,resize}MutableByteArray#` primitives),
some of the nofib benchmarks actually results in increased allocation
numbers (but not necessarily an increase in runtime!).  I believe the
allocation numbers could improve if `{resize,shrink}MutableByteArray#`
could be optimised to reallocate in-place more efficiently.

Here are the more apparent changes in the latest nofib comparision
between `integer-gmp` and `integer-gmp2`:

  ------------------------------------------------------------------
          Program     Size    Allocs   Runtime   Elapsed  TotalMem
  ------------------------------------------------------------------
              ...
       bernouilli    +1.6%    +15.3%     0.132     0.132      0.0%
              ...
     cryptarithm1    -2.2%      0.0%     -9.7%     -9.7%      0.0%
              ...
            fasta    -0.7%     -0.0%    +10.9%    +10.9%      0.0%
              ...
            kahan    +0.6%    +38.9%     0.169     0.169      0.0%
              ...
             lcss    -0.7%     -0.0%     -6.4%     -6.4%      0.0%
              ...
           mandel    +1.6%    +33.6%     0.049     0.049      0.0%
              ...
         pidigits    +0.8%     +8.5%     +3.9%     +3.9%      0.0%
            power    +1.4%    -23.8%    -18.6%    -18.6%    -16.7%
              ...
        primetest    +1.3%    +50.1%     0.085     0.085      0.0%
              ...
              rsa    +1.6%    +53.4%     0.026     0.026      0.0%
              ...
              scs    +1.2%     +6.6%     +6.5%     +6.6%    +14.3%
              ...
           symalg    +1.0%     +9.5%     0.010     0.010      0.0%
              ...
        transform    -0.6%     -0.0%     -5.9%     -5.9%      0.0%
              ...
  ------------------------------------------------------------------
              Min    -2.3%    -23.8%    -18.6%    -18.6%    -16.7%
              Max    +1.6%    +53.4%    +10.9%    +10.9%    +14.3%
   Geometric Mean    -0.3%     +1.9%     -0.8%     -0.8%     +0.0%

(see P35 / https://phabricator.haskell.org/P35 for full report)

By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results
in the package `integer-gmp-1.0.0.0` being registered in the package db.
The previous `integer-gmp-0.5.1.0` can be restored by setting
`INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether
for GHC 7.12). In-tree GMP support has been stolen from the old
`integer-gmp` (while unpatching the custom memory-allocators, as well as
forcing `-fPIC`)

A minor hack to `ghc-cabal` was necessary in order to support two different
`integer-gmp` packages (in different folders) with the same package key.

There will be a couple of follow-up commits re-implementing some features
that were dropped to keep D82 minimal, as well as further
clean-ups/improvements.

More information can be found via #9281 and
https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2

Reviewed By: austin, rwbarton, simonmar

Differential Revision: https://phabricator.haskell.org/D82

Use fewer left/right-biased folds for defaults and
functions in `Data.Foldable`, to better support things
that don't look like cons lists.

This also extends the Haddock docstrings in `Data.Foldable`.

Reviewed By: hvr, ekmett

Differential Revision: https://phabricator.haskell.org/D441

Define list monad operations using list comprehensions. Code using monad
operations with lists did not fuse fully. Writing list code with `do`
notation or `(>>=)` and `(>>)` operations could allocate more than
equivalent code using list comprehensions.

Define `mapM` directly, instead of using `sequence` and `map`. This
leads to substantially less allocation in `cryptarithm2`.

Addresses #9781

Reviewed By: ekmett, nomeata

Differential Revision: https://phabricator.haskell.org/D455

This also updates the `transformers` submodule to the just
released `transformers-0.4.2.0` package version.

See #9664 for more details

Reviewed By: austin, ekmett

Differential Revision: https://phabricator.haskell.org/D313

Control.Applicative previously imported `(.)` and `id` from `Control.Arrow`,
but then only applied them to functions.

Reviewed By: ekmett, hvr

Differential Revision: https://phabricator.haskell.org/D462

This is a follow-up commit to df3b1d43

This makes nub and nubBy behave as specified in the Haskell 98 Report.

This reverts 0ad9def5, and
fixes #3280, #7913 and #2528 (properly).

Before this change, the output of `T2528` was (4x wrong):
```
[A,B]
[1,2]
False
False
```

Reviewed By: dfeuer, ekmett, austin, hvr

Differential Revision: https://phabricator.haskell.org/D238