GitLab

For one this compensates for `Word` being exported from `Prelude` only with
base >= 4.8, and moreover this brings the well-known {Int,Word}{8,16,32,64}
names into scope by default when using the Compat.Prelude.

Profiling showed that there are quite a few 'Ord' calls (~70k calls)
which result in 'versionNumbers' being evaluated because the need to
compare with Versions not fitting in a Word64 becomes necessary, mostly
when inserting into a `Map`. So I've optimised this a bit more.  After
some experimentation, the new `compare` implemetation results in faster
comparisions (`cmpOpt` is the new optimised impl, `compare` is the
previous naive one):

comparing two PV1 constructors:

    benchmarking compare 1.2.3.4.5 1.2.3.4.5
    time                 42.33 ns   (42.17 ns .. 42.47 ns)
                         1.000 R²   (1.000 R² .. 1.000 R²)
    mean                 42.17 ns   (42.13 ns .. 42.28 ns)
    std dev              205.1 ps   (128.7 ps .. 325.7 ps)

    benchmarking cmpOpt  1.2.3.4.5 1.2.3.4.5
    time                 33.31 ns   (33.23 ns .. 33.40 ns)
                         1.000 R²   (1.000 R² .. 1.000 R²)
    mean                 33.37 ns   (33.29 ns .. 33.46 ns)
    std dev              288.6 ps   (242.9 ps .. 315.8 ps)

    benchmarking compare [1.2.3.4.5] [1.2.3.4.5]
    time                 31.92 ns   (31.89 ns .. 31.94 ns)
                         1.000 R²   (1.000 R² .. 1.000 R²)
    mean                 31.89 ns   (31.88 ns .. 31.91 ns)
    std dev              37.09 ps   (24.38 ps .. 54.82 ps)

comparing a PV0 constructor with a PV1 constructor when the first digit
decides the outcome:

    benchmarking compare 2.3.4 1.2.3.4.5
    time                 24.96 ns   (24.78 ns .. 25.25 ns)
                         0.996 R²   (0.989 R² .. 1.000 R²)
    mean                 25.50 ns   (24.95 ns .. 26.95 ns)
    std dev              2.802 ns   (1.275 ns .. 5.163 ns)
    variance introduced by outliers: 93% (severely inflated)

    benchmarking cmpOpt  2.3.4 1.2.3.4.5
    time                 11.29 ns   (11.27 ns .. 11.30 ns)
                         1.000 R²   (1.000 R² .. 1.000 R²)
    mean                 11.28 ns   (11.27 ns .. 11.29 ns)
    std dev              24.69 ps   (12.02 ps .. 46.86 ps)

    benchmarking compare [2.3.4] [1.2.3.4.5]
    time                 11.05 ns   (11.04 ns .. 11.06 ns)
                         1.000 R²   (1.000 R² .. 1.000 R²)
    mean                 11.05 ns   (11.04 ns .. 11.06 ns)
    std dev              32.82 ps   (15.89 ps .. 61.64 ps)

These timings are now very close to the 'Ord [Int]' timings.

With this optimisation, the total number of 'versionNumbers' calls
reported by `+RTS -p` for `cabal new-build --dry`'ing haskell-ide-engine
went down from originally 73501 calls to 6789 calls.

This optimises the `[Int]` representation to a 16-byte heap object for
~99% of version numbers (up to 4 components, each within a [0..0xfffe]
value range) occuring on Hackage.

One noteworthy improvement of this optimisation is a significant reduction
of the size of the 01-index.cache file from previously 6299700 bytes
(before #3905) down to 3408864 bytes, i.e. down to ~54%

Also, this reduces the memory footprint and GC overhead a bit for
e.g. `cabal info zzz` (which reads in the index cache) from

    cabal.0: There is no package named 'zzz'.
    You may need to run 'cabal update' to get the latest list of available
    packages.
         859,337,368 bytes allocated in the heap
         447,261,128 bytes copied during GC
          37,385,208 bytes maximum residency (19 sample(s))
           1,311,136 bytes maximum slop
                 103 MB total memory in use (0 MB lost due to fragmentation)

                                         Tot time (elapsed)  Avg pause  Max pause
      Gen  0      1613 colls,     0 par    0.268s   0.268s     0.0002s    0.0012s
      Gen  1        19 colls,     0 par    0.227s   0.227s     0.0119s    0.0506s

      TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)

      SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

      INIT    time    0.001s  (  0.001s elapsed)
      MUT     time    0.431s  (  0.758s elapsed)
      GC      time    0.495s  (  0.495s elapsed)
      EXIT    time    0.006s  (  0.005s elapsed)
      Total   time    0.934s  (  1.259s elapsed)

      Alloc rate    1,991,870,623 bytes per MUT second

      Productivity  46.9% of total user, 34.8% of total elapsed

to

    cabal.1: There is no package named 'zzz'.
    You may need to run 'cabal update' to get the latest list of available
    packages.
         834,314,392 bytes allocated in the heap
         440,791,176 bytes copied during GC
          36,663,112 bytes maximum residency (19 sample(s))
           2,225,040 bytes maximum slop
                  96 MB total memory in use (0 MB lost due to fragmentation)

                                         Tot time (elapsed)  Avg pause  Max pause
      Gen  0      1574 colls,     0 par    0.254s   0.254s     0.0002s    0.0007s
      Gen  1        19 colls,     0 par    0.223s   0.223s     0.0118s    0.0474s

      TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)

      SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

      INIT    time    0.001s  (  0.001s elapsed)
      MUT     time    0.383s  (  0.699s elapsed)
      GC      time    0.477s  (  0.477s elapsed)
      EXIT    time    0.005s  (  0.005s elapsed)
      Total   time    0.869s  (  1.182s elapsed)

      Alloc rate    2,175,866,164 bytes per MUT second

      Productivity  44.9% of total user, 33.0% of total elapsed

Similiar to dabd9d98 which made
`PackageName` opaque, this makes `Distribution.Version.Version` opaque.

The most common version numbers occuring on Hackage are 3- and
4-part versions. This results in significant Heap overhead due to
`Data.Version`'s inefficient internal representation.

So like the `PackageName` commit, this commit is a preparatory commit to
pave the way for replacing `Version`'s internal representation by a
representation with a memory footprint which can be an order of
magnitude smaller.

Finally, this also adds a new functor-like convenience function

    alterVersion :: ([Int] -> [Int]) -> Version -> Version

for modifying the version number components.

When 'read' is used on invalid input, it raises a "no parse" exception that is
typically very unhelpful to the user.  It is generally more desirable to either
handle the error or produce a more helpful error message.

This actually happens sometimes.  When a user creates a detailed-0.9 test
suite, and that test suite crashes or is killed so it can't write its result
log, the bare read in Distribution.Simple.Test.LibV09.runTest fails and cabal
fails with "no parse".

I could have just written a patch to fix that, but it seemed like a better idea
to find all uses of bare read and see what we can do for all of them.

I have grepped through the repository and I think I've found all uses of bare
'read' that might raise the dreaded 'no parse' exception.  The plan is to
separately patch each of them by either replacing with an alternate Read
function (readMaybe is the most obvious candidate), proving the read will
always succeed, or establishing that producing a 'no parse' exception is the
most desirable behavior.

This implements a new syntactic sugar: The version range operator
`^>=` which is equivalent to `>=` intersected with an
automatically inferred major upper bound.

This new syntax is only allowed for `cabal-version: >=2.0`, and
allows to describe the most common use of version
bounds more conveniently:

    build-depends: foo ^>= 1.2.3.4,
                   bar ^>= 1

The declaration above is exactly equivalent to

    build-depends: foo >= 1.2.3.4 && < 1.3,
                   bar >= 1 && < 1.1

This also helps with the issue of the wildcard operator having the
surprising effect that e.g. `== 1.0.*` does not include the single 
digit version `1`.

The `^`-symbol was chosen because it can serve as a mnemonic when the
`>` sign is rotated and interpreted as "less than ceiling"

Moreover, `^` appears to become a quasi-standard to denote morally
equivalent operator that way in other language ecosystems which similiar
to Haskell have adopted semantic versioning:

 - Node: https://nodesource.com/blog/semver-tilde-and-caret/
 - Bower: https://bower.io/docs/api/#install
 - PHP: https://getcomposer.org/doc/articles/versions.md#caret

Ruby, on the other hand, uses a Tilde operator (`~>`) for that
purpose (but with a less robust semantic):

 - https://blog.codeship.com/optimists-guide-pessimistic-library-versioning

And Python is currently planing to use an `~=` operator:

 - https://www.python.org/dev/peps/pep-0440/#compatible-release

This implements the flag `--allow-older` which is the analogous to
`--allow-newer` acting on lower bounds.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Simon Jakobi authored Jul 02, 2016 and Mikhail Glushenkov committed Jul 06, 2016

(cherry picked from commit 0562d952)

Fixes #3003.

Try and pick the right default for ghc-8.

Instead of qualifying, in some cases I just added an extra
'hiding' pragma to squelch errors.  Common conflicts
(just grep for hiding):

    - Flag
        - Distribution.Simple.Compiler
        - Distribution.PackageDescription
        - Distribution.Simple.Setup
    - installedComponentId
        - Distribution.Package
        - Distribution.InstalledPackageInfo
    - doesFileExist
        - Distribution.PackageDescription.Check
    - instantiatedWith
        - I renamed the field in InstalledPackageInfo.  But
          it's probably going away with Backpack bits; I
          migth just excise it soon.
    - absoluteInstallDirs and substPathTemplate
        - Distribution.Simple.InstallDirs
        - Distribution.Simple.LocalBuildInfo

I fixed some shadowing errors by renaming local variables in some cases.
Common shadowings (we should perhaps consider not using these as
method/field names):

    - freeVars
    - components
    - noVersion
    - verbosity
    - get
    - description
    - name

Some data structures were moved around (IPIConvert and ABIHash)
to make it easier to handle import lists.

Some functions in Utils could be turned into reexports of standard
library functions.

No explicit imports were removed from non-Cabal imports.  These
imports help maintain warning cleanliness across versions of GHC,
so I don't recommend removing them.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is useful for performing PVP bounds checking, especially for
tooling that wants to automate such dependency bounds. A demonstration
of this being used in practice is the --pvp-bounds flag for stack:

https://github.com/commercialhaskell/stack/commit/c774f9905b3b112f58fc3789dfb9c26389d33b24

Redundant parens. Was breaking one test.

GHC generics are used to derive binary instances for types appearing
in the persistent build config, which requires GHC >= 7.2 and
binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
The missing module is Data.Binary.Generics, which we have copied from
binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
generic implementations for the Binary class, we also have to provide
our own implementation, which is copied from binary-0.7.2.3 to
Distribution.Compat.Binary.Class. The interface required by Cabal is
exported from Distribution.Compat.Binary. This is only done if
bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
otherwise Distribution.Compat.Binary simply re-exports Data.Binary.

Avoids deprecation warnings when versionTags is deprecated in GHC 7.10
(GHC ticket #2496)

Bertram Felgenhauer authored Sep 07, 2014 and Mikhail Glushenkov committed Oct 21, 2014

The motivation is to be able to say --constraint 'foo -none' to prevent
'foo' from being considered when installing packages. See #2092.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

It's just noise that duplicates information in the 'LICENSE' file.

Herbert Valerio Riedel authored Sep 13, 2013 and tibbe committed Sep 13, 2013

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Fixes #1496 (presumably).